Yedekleme için 3-2-1 kuralı ve yedeği olmayanların başına gelenler

Yıllar içinde yedekle ilgili en çok duyduğum cümle şu: "Yedek alıyorduk ama…" Cümlenin devamı genellikle aynı birkaç sebepten biridir. Yedek aynı diskteydi ve disk gitti. Yedek alınıyordu ama altı aydır hata veriyordu ve kimse bakmamıştı. Ya da yedek vardı ama veritabanı içinde değildi.

3-2-1 kuralı

Kural basit ve fotoğrafçılık dünyasından gelir:

• 3 kopya veri: biri canlı, ikisi yedek.
• 2 farklı ortam: örneğin sunucu diski ve bir nesne depolama servisi.
• 1 kopya başka bir yerde, yani farklı bir fiziksel lokasyonda ya da farklı bir sağlayıcıda.

Son yıllarda buna iki madde daha eklendi: Kopyalardan birinin değiştirilemez (immutable) ya da çevrimdışı olması ve yedeklerin düzenli olarak geri yüklenip test edilmesi. Fidye yazılımları, sunucuya erişebilen her yedeği de şifrelemeye çalışır. Sunucudan silinemeyen bir kopya bu yüzden önemlidir.

Neyi yedekliyoruz?

Tipik bir web sunucusunda dört şey vardır:

1. Dosyalar: Site kodu, yüklenen görseller (wp-content/uploads gibi).
2. Veritabanları: Ayrıca alınmalıdır. Çalışan bir MySQL'in dosyalarını kopyalamak tutarlı bir yedek vermez.
3. Yapılandırma: /etc altındaki web sunucusu, PHP, e-posta ayarları; cron görevleri.
4. E-postalar: Sunucuda posta barındırıyorsanız.

Veritabanını doğru almak

mysqldump --single-transaction --quick --routines --triggers veritabani | gzip > /yedek/db-$(date +%F).sql.gz

--single-transaction, InnoDB tablolarında siteyi kilitlemeden tutarlı bir anlık görüntü alır. --quick büyük tabloları belleğe tek seferde yüklemez.

Dosyalar: rsync ya da restic

En basit yöntem, rsync ile başka bir sunucuya kopyalamaktır:

rsync -az --delete /home/ yedek@yedek-sunucu:/yedekler/web01/home/

Ancak bu yöntem yalnızca son hâli saklar. Dün yanlışlıkla silinen bir dosya bu gece yedekten de silinir. Geçmişe dönük sürümler için restic ya da borg gibi araçlar daha uygundur. Bu araçlar tekilleştirme (deduplication) yapar, yedeği şifreler ve "her gün 7, her hafta 4, her ay 6 kopya tut" gibi saklama kurallarını kendileri uygular:

restic -r s3:https://depolama.ornek/yedek backup /home /etc /yedek/db
restic -r s3:https://depolama.ornek/yedek forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Yedeğin çalıştığını nereden bileceksiniz?

Yedeklerin en büyük düşmanı sessiz başarısızlıktır. Betik bir gün hata vermeye başlar ve kimse fark etmez. Bunun için:

• Yedek betiği bitince bir "nabız" adresine istek atsın. İstek gelmezse size bildirim gelsin. Healthchecks.io gibi servisler ya da kendi küçük kontrolünüz bu işi görür.
• Yedek dosyalarının boyutunu izleyin. Dünkü yedek 2 GB, bugünkü 4 KB ise bir şeyler ters gitmiştir.

Geri yükleme testi

Hiç geri yüklenmemiş bir yedek, aslında yalnızca bir umuttur. Ayda bir kez, rastgele bir siteyi test ortamına geri yükleyin:

1. Dosyaları boş bir klasöre açın.
2. Veritabanını yeni bir veritabanına içeri aktarın.
3. Sitenin açıldığını, son yazıların ve siparişlerin yerinde olduğunu kontrol edin.
4. Geri yüklemenin ne kadar sürdüğünü not edin. Bir felaket anında "ne zaman açılacak?" sorusunun cevabı bu süredir.

Küçük bir sunucu için uygulanabilir düzen

• Her gece veritabanı dökümü ve dosyalar restic ile başka bir sağlayıcıdaki nesne depolamaya gönderilir.
• Hosting sağlayıcısının haftalık anlık görüntüleri (snapshot) ikinci katman olarak açık tutulur.
• Ayda bir geri yükleme testi yapılır ve sonucu bir yere not edilir.

Bu düzenin aylık maliyeti çoğu zaman bir kahve parasıdır. Yedeksiz bir felaketin maliyeti ise genellikle o siteyle birlikte biter.