Bir işletmeye yedeklerinin olup olmadığını sorun, yanıt genellikle “evet” olur. Ancak en son ne zaman bir geri yükleme testi yaptıklarını sorduğunuzda, ortam sessizleşir. Donanım arızaları, fidye yazılımları, hacklenmiş eklentiler, yanlış rm -rf komutu veya başarısız bir güncelleme herhangi bir sunucuda meydana gelebilir. Yedekler, onlardan geri yükleme yapabiliyorsanız yalnızca değerlidir.
Bu kılavuz, 3-2-1 kuralı ve restic kullanarak Linux sunucuları (web mağazaları, WordPress, Magento, n8n ve diğer uygulamalar) için basit, güvenilir bir yedekleme kurulumu göstermektedir.
3-2-1 yedekleme kuralı
- 3 kopya veriniz (orijinal artı iki yedek)
- 2 farklı depolama türü üzerinde
- 1 kopya dışarıda
Birçok kişi modern bir uzantı ekler: 3-2-1-1-0:
- 1 kopya çevrimdışı veya değiştirilemez (bir saldırgan tarafından değiştirilemez veya silinemez)
- 0 hata geri yükleme testlerinde
Neleri yedeklemeli
Tipik bir web sunucusu için:
- Veritabanları (MySQL/MariaDB, PostgreSQL), tutarlı yedekler olarak
- Uygulama dosyaları: yüklemeler, medya,
wp-content,pub/media, yapılandırma dosyaları - Yapılandırma: web sunucusu yapılandırması,
.envdosyaları, cron görevleri, SSL ayarı - Sırlar: şifreleme anahtarları ve kimlik bilgileri, ayrı bir şifre yöneticisinde saklanır
Yeniden inşa edebileceğiniz şeyleri yedeklemeyin: önbellekler, generated/ kodu, node_modules, vendor/ (eğer Git ve Composer’dan dağıtım yapıyorsanız).
Neden restic?
Restic, ücretsiz, açık kaynaklı bir yedekleme aracıdır ki:
- Varsayılan olarak Şifreli
- Tekilleştirilmiş: yalnızca değişen veriler saklanır, bu nedenle günlük yedeklemeler küçüktür.
- Birçok hedefe yedekleme yapabilme: yerel disk, SFTP, S3 uyumlu nesne depolama, Backblaze B2 ve daha fazlası
- Komut satırından kullanımı basit
Borg (borgmatic ile) benzer özelliklere sahip iyi bir alternatiftir.
Adım 1: restic’i kurun
Debian/Ubuntu’da:
sudo apt install restic
Adım 2: Bir depo oluşturun
S3 uyumlu nesne depolama ile örnek:
export AWS_ACCESS_KEY_ID=your-key
export AWS_SECRET_ACCESS_KEY=your-secret
export RESTIC_REPOSITORY=s3:https://s3.example-provider.com/my-backups
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
Restic şifresini bir şifre yöneticisinde de saklayın. Bunun olmaması durumunda, yedekleriniz şifresi çözülemez.
Adım 3: Veritabanlarını dökün
MySQL / MariaDB (InnoDB için dükkanı kilitlemeden tutarlı yedekleme):
mysqldump --single-transaction --quick --routines --triggers shop_db | gzip > /var/backups/db/shop_db.sql.gz
PostgreSQL:
pg_dump -U app app_db | gzip > /var/backups/db/app_db.sql.gz
Adım 4: Yedeklemeyi çalıştırın
restic backup /var/backups/db /var/www/shop/pub/media /etc/nginx /home/deploy/.env \
--exclude /var/www/shop/var/cache
Adım 5: Saklama süresini ayarlayın
Mantıklı bir geçmiş tutun ve eski anlık görüntüleri kaldırın:
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
Bu, bir hafta boyunca günde bir yedek, bir ay boyunca haftada bir yedek ve altı ay boyunca ayda bir yedek tutar.
Adım 6: Depo bütünlüğünü kontrol et
restic check
Bunu düzenli olarak, örneğin haftada bir çalıştırın.
Adım 7: Bir betik ve cron ile otomatikleştirin
Create /usr/local/bin/backup.sh:
#!/bin/bash
set -euo pipefail
source /root/.restic-env
mysqldump --single-transaction --quick shop_db | gzip > /var/backups/db/shop_db.sql.gz
restic backup /var/backups/db /var/www/shop/pub/media /etc/nginx
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
Bunu gece planlayın:
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
İzleme ekleyin. Üç ay boyunca sessizce başarısız olan bir yedekleme, yaygın bir felakettir. Yedeklemenin başarı bildirmediğinde sizi uyaran bir “ölü adamın anahtarı” izleme hizmeti veya küçük bir iş akışı kullanın.
Adım 8: Geri yüklemeleri test et
Anlık görüntüleri listele:
restic snapshots
Bir test konumuna geri yükle:
restic restore latest --target /tmp/restore-test
En azından her birkaç ayda bir, ayrı bir test sunucusuna geri yükleyin ve uygulamanın gerçekten çalıştığını kontrol edin. Yedeklerinizin işe yaradığını kanıtlayan tek gerçek delil budur.
Ransomware’a karşı korunma
Eğer bir saldırgan sunucunuzda root erişimi elde ederse, sunucunun yazabileceği yedekleri de silebilir. Kendinizi korumak için:
- Sadece ekleme veya değiştirilemez depolama (nesne kilidi / S3 uyumlu depolamada sürümleme)
- Ayrı bir yedekleme sunucusundan yedekleri alın, böylece web sunucusunun silme yetkisi olmaz.
- Üretim sunucusunda saklanmayan ayrı kimlik bilgileri mümkünse
Anlık görüntüler vs yedeklemeler
VPS ve bulut anlık görüntüleri, güncellemelerden önce hızlı geri dönüşler için faydalıdır, ancak genellikle aynı sağlayıcıda ve bazen aynı konumda saklanır. Onları yerine geçmek yerine, yerinde olmayan yedeklemelere ek olarak kullanın.
Yedekleme kontrol listesi
| Öğe | Tamam mı? |
|---|---|
| Veritabanları sürekli olarak döküldü | |
| Medya ve yapılandırma dosyaları dahil edildi | |
| Yer dışında şifrelenmiş kopya | |
| Değiştirilemez veya çevrimdışı kopya | |
| Saklama politikası ayarlandı | |
| İzleme ve uyarılar | |
| Son 3 ayda test edilen geri yükleme | |
| Şifre yöneticisindeki şifreler ve anahtarlar |
Sıkça sorulan sorular
Web mağazamı ne sıklıkla yedeklemeliyim?
Çoğu mağaza için günde en az bir kez. Birçok sipariş alan yoğun mağazalar, genellikle veritabanını daha sık yedekler veya replikasyon ile anlık geri yükleme kullanır.
Hosting sağlayıcımın yedeği yeterli mi?
Bu, faydalı bir ek katmandır, ancak genellikle saklama, konum veya geri yükleme hızını kontrol edemezsiniz. Kendi dış yedeklemenizi de bulundurun.
Restic mi yoksa Borg mu?
Her ikisi de mükemmel. Restic, birçok bulut depolama arka ucunu doğrudan destekler; Borg ise çok verimlidir ve genellikle SSH tabanlı depolama ile kullanılır. Depolama hedefinize en uygun olanı seçin.
Güvenebileceğiniz yedeklere mi ihtiyacınız var?
Web mağazaları ve iş uygulamaları için sunucuları, yedeklemeleri ve geri yükleme prosedürlerini kuruyor ve sürdürüyorum. sunucularım, sanallaştırma ve yedekleme hizmetimi veya yardım isteyin kısmına bakın.