Sunucu Yedekleme Stratejisi: 3-2-1 Kuralını Uygulamak

3-2-1 kuralı nedir?

3-2-1, veri koruma alanında uzun süredir kullanılan basit bir ölçüttür: verinizin en az üç kopyası olsun, bu kopyalar en az iki farklı depolama ortamında dursun ve en az bir kopya başka bir fiziksel konumda bulunsun. Sunucu dünyasında bunun pratik karşılığı genellikle şöyledir: canlı veri sunucunun diskinde, bir kopya aynı sağlayıcının snapshot veya yedek hizmetinde, bir kopya da tamamen farklı bir sağlayıcıdaki nesne depolama alanında ya da ofisinizdeki bir diskte.

Kuralın amacı, tek bir olayın tüm kopyaları birden yok etmesini engellemektir. Aynı sunucudaki ikinci bir klasöre alınan yedek, disk arızasında da, sunucuya sızan bir saldırganın elinde de canlı veriyle birlikte kaybolur. Son yıllarda bu kurala sık sık değiştirilemez (immutable) ya da çevrim dışı bir kopya ve düzenli geri yükleme testi de ekleniyor; özellikle fidye yazılımlarına karşı bu iki ek önemlidir.

Neyi yedeklemeniz gerekiyor?

Tüm diski kopyalamak kolay görünür ama geri yüklemesi hantal ve depolaması pahalı olabilir. Çoğu web sunucusu için şu dört grup yeterlidir:

E-posta sunucuyu da aynı makinede çalıştırıyorsanız posta kutuları da listeye girer. Panel kullanıyorsanız cPanel, Plesk ve DirectAdmin gibi panellerin hesap bazlı yedek araçları bu grupların çoğunu tek pakette toplar; bu araçların farkları için panel karşılaştırması rehberimize bakabilirsiniz. Panel yedeği almak, onu başka bir konuma göndermediğiniz sürece 3-2-1 kuralını karşılamaz.

Veritabanı yedeğini doğru almak

Çalışan bir veritabanının dosyalarını doğrudan kopyalamak tutarsız bir yedek üretebilir. Bunun yerine veritabanının kendi döküm aracını kullanın. MySQL ve MariaDB için InnoDB tablolarında tutarlı bir döküm almak üzere mysqldump --single-transaction --routines --triggers veritabani_adi kalıbı yaygın olarak kullanılır; çıktıyı gzip ile sıkıştırıp tarihli bir dosyaya yazabilirsiniz. PostgreSQL için karşılığı pg_dump aracıdır.

Birkaç pratik öneri:

• Veritabanı parolasını komut satırına yazmayın; yalnızca sizin okuyabildiğiniz bir seçenek dosyasında (örneğin MySQL için ~/.my.cnf) tutun.
• Büyük veritabanlarında döküm işlemi diske ve işlemciye yük bindirir. Yedeği trafiğin en düşük olduğu saate planlayın.
• Birden çok veritabanınız varsa her birini ayrı dosyaya dökün; tek bir sitenin verisini geri yüklemek gerektiğinde diğerlerine dokunmazsınız.
• Döküm dosyasının boyutunu her gün kaydedin. Bir gün aniden çok küçülmesi, yedeğin yarıda kesildiğinin en hızlı işaretidir.

Uzak kopya ve şifreleme

Yedeği sunucudan çıkarmanın birkaç yolu vardır: rsync ile başka bir sunucuya eşitleme, S3 uyumlu bir nesne depolama hizmetine yükleme ya da yedeği sunucunun çekmesi yerine ayrı bir yedek makinesinin sunucudan çekmesi. Son yöntemin bir avantajı vardır: canlı sunucu ele geçirilse bile saldırgan yedek makinesine erişemez, çünkü kimlik bilgileri canlı sunucuda değil yedek makinesinde durur.

restic ve BorgBackup gibi açık kaynak yedekleme araçları tekrarlanan veriyi bir kez saklar (deduplikasyon), yedekleri şifreler ve geçmiş sürümleri tutar. Hangi aracı seçerseniz seçin şu kurallar değişmez:

• Yedekler sunucudan çıkmadan önce şifrelenmeli, şifreleme anahtarı da sunucudan ayrı bir yerde saklanmalıdır. Anahtarı kaybederseniz yedek de kaybolur.
• Uzak depolamaya yazma yetkisi olan hesabın silme yetkisi olmamalı ya da depolama tarafında sürümleme veya nesne kilidi açık olmalıdır.
• Kişisel veri barındırıyorsanız yedeklerin de veri koruma yükümlülüklerinizin kapsamında olduğunu unutmayın.

Saklama süresi ve zamanlama

Yalnızca "dünkü" yedeği tutmak yetmez; bir sorun, örneğin bir zararlı kod bulaşması, ancak birkaç gün sonra fark edilebilir. Yaygın bir düzen, günlük yedeklerden son 7 günü, haftalıklardan son 4 haftayı ve aylıklardan son birkaç ayı saklamaktır. Bu sayıları sitenizin ne kadar sık değiştiğine ve depolama bütçenize göre ayarlayın.

Zamanlamayı cron veya systemd zamanlayıcılarıyla otomatikleştirin ve her çalışmanın sonucunu bir yere bildirin. Sessizce başarısız olan bir yedek, hiç olmayan bir yedekten daha tehlikelidir, çünkü size sahte bir güven verir. Başarısız işi e-postayla bildiren basit bir betik ya da yedek işinin her başarılı çalışmada dış bir izleme adresine sinyal göndermesi işe yarar. Sinyal gelmediğinde alarm üreten izleme yöntemini sunucu kaynak izleme rehberinde anlattık.

Geri yükleme testi: yedeğin gerçek sınavı

Bir yedeğin çalıştığını bilmenin tek yolu onu geri yüklemektir. Ayda bir kez şu tatbikatı yapın:

1. Küçük, geçici bir sunucu ya da yerel bir sanal makine açın.
2. En son yedeği yalnızca belgelerinize bakarak geri yükleyin. Belgelemediğiniz bir adım varsa not alın.
3. Veritabanı dökümünü içe aktarın, sitenin açıldığını ve son eklenen içeriğin yerinde olduğunu kontrol edin.
4. Toplam süreyi ölçün. Bu, gerçek bir felakette sitenizin ne kadar kapalı kalacağının iyi bir tahminidir.
5. Test sunucusunu silin ve sonucu kısa bir notla kaydedin.

Geri yükleme tatbikatı aynı zamanda iyi bir taşıma provasıdır. Yedeği yeni bir sunucuya açıp alan adını oraya yönlendirdiğinizde fiilen site taşımış olursunuz; DNS tarafındaki adımlar için domain ve DNS yönetimi sayfamıza bakabilirsiniz.

Örnek senaryo: tek VPS'te çalışan bir içerik sitesi

Somut bir örnek üzerinden düşünelim. Tek bir VPS üzerinde bir içerik sitesi ve onun MySQL veritabanı çalışıyor, site dosyaları birkaç gigabayt, veritabanı birkaç yüz megabayt. Bu durumda makul bir düzen şöyle kurulabilir:

• Kopya 1: canlı veri, sunucunun diskinde.
• Kopya 2: sağlayıcının haftalık snapshot hizmeti; büyük bir hatada tüm sunucuyu dakikalar içinde geri döndürmek için.
• Kopya 3: her gece alınan veritabanı dökümü ve site dosyaları, şifrelenip başka bir sağlayıcıdaki nesne depolama alanına gönderilir; sürümleme açıktır.
• Ek önlem: ayda bir, son aylık yedek çevrim dışı bir diske indirilir.

Bu düzende disk arızası snapshot ile, hatalı bir güncelleme dünkü dökümle, sağlayıcı hesabına erişimin kaybedilmesi ise başka sağlayıcıdaki kopya ile telafi edilir. Her senaryoya bir cevap olması, kuralın asıl amacıdır.

Sık yapılan yedekleme hataları

• Yedeği yalnızca aynı sunucuda ya da aynı sağlayıcı hesabında tutmak.
• Veritabanını unutup yalnızca dosyaları yedeklemek.
• Şifreleme parolasını yalnızca yedeklenen sunucuda saklamak.
• Yedek işinin hata verdiğini haftalarca fark etmemek.
• Hiç geri yükleme denemesi yapmamak.
• Geri yükleme adımlarını yalnızca bir kişinin aklında tutmak; o kişi ulaşılamaz olduğunda yedek de işe yaramaz hale gelir.

Son madde küçük ekiplerde sık görülür. Yedeğin nerede durduğunu, şifreleme anahtarının kimde olduğunu ve geri yüklemenin hangi sırayla yapıldığını kısa bir belgeye yazın ve bu belgeyi sunucunun dışında saklayın. Felaket anında aranacak ilk şey o belge olacaktır. Belgeye alan adı ve DNS hesaplarının nerede yönetildiğini de ekleyin; yeni sunucuya geçtiğinizde kayıtları güncellemeniz gerekecek.

Yedekleme, güvenlik sertleştirmesinin tamamlayıcısıdır; ikisini birlikte kurmak için VPS güvenlik ayarları rehberine de göz atın. Tüm sunucu işlerinin özeti sunucu yönetimi sayfasında. Kullandığınız yedekleme aracı ya da depolama hizmetiyle ilgili deneyimleri Sunucu/Hosting Bilgi Alışverişi bölümünde sorabilir, betik hatalarınızı Linux Sunucular bölümünde paylaşabilirsiniz.

Forumdaki ilgili bölümler

• Sunucu/Hosting Bilgi AlışverişiYedekleme araçları ve depolama deneyimleri.
• Linux SunucularYedek betikleri, cron ve geri yükleme sorunları.
• MySQLVeritabanı dökümü ve içe aktarma soruları.

Sık sorulan sorular