Yedekleme stratejisi: 3-2-1 kuralı ve geri dönüş provası

Yedekleme sorusunun doğru hali "yedek alıyor muyum?" değil, "en son ne zaman geri döndüm ve ne kadar sürdü?" olmalıdır. Alınmış ama hiç denenmemiş yedek, olmayan yedekle aynı güveni verir. Aşağıdaki çerçeve, küçük bir kurumsal siteden veritabanı ağırlıklı bir uygulamaya kadar ölçeklenir.

İki rakamı önce siz belirleyin

Teknik çözüm seçmeden önce iş tarafında iki soruyu cevaplayın:

• RPO (kabul edilebilir veri kaybı): Kaç saatlik veriyi kaybetmeyi göze alabilirsiniz? Tanıtım sitesinde 24 saat sorun değildir; sipariş alan bir sitede bir saat bile çok olabilir.
• RTO (kabul edilebilir kesinti): Site kaç saat kapalı kalabilir?

RPO yedekleme sıklığını, RTO ise yöntemi belirler. Günlük yedek alıp geri dönüşü altı saat süren bir düzenek, bir saatlik RTO hedefiyle bağdaşmaz.

3-2-1 kuralı

Kural basittir ve otuz yıldır geçerliliğini koruyor: 3 kopya, 2 farklı ortam, 1 kopya farklı fiziksel konumda.

• Birinci kopya çalışan sistemin kendisidir.
• İkinci kopya aynı sunucudaki ya da aynı veri merkezindeki yedek alanıdır; hızlı geri dönüş buradan yapılır.
• Üçüncü kopya başka bir konumdadır. Sunucunun tamamı kaybolduğunda tek dayanağınız budur.

Aynı sunucunun ikinci diskine alınan yedek, üç kopyadan sayılmaz. Diski değil sunucuyu kaybettiğiniz senaryoda ikisi birden gider.

Neyi yedekliyorsunuz?

Eksik yedeklerin klasik sebebi, listenin baştan yanlış çıkarılmasıdır. En az şunlar olmalı:

1. Web kök dizini ve yüklenen dosyalar.
2. Veritabanı dökümü — dosya kopyası değil, tutarlı bir mysqldump çıktısı.
3. Web sunucusu, PHP ve e-posta yapılandırma dosyaları.
4. TLS sertifikaları ve özel anahtarlar.
5. Zamanlanmış görevler (crontab) ve servis birimleri.
6. DNS bölge kayıtlarının bir kopyası.

Veritabanı dosyalarını çalışırken kopyalamak bozuk yedek üretir. InnoDB tablolarında mysqldump --single-transaction kullanın; tabloları kilitlemeden tutarlı bir görüntü alır.

Dökümü doğru almanın komutu

mysqldump --single-transaction --quick --routines --triggers --events --default-character-set=utf8mb4 veritabani | gzip > yedek.sql.gz

Bayrakların her biri bir hatayı önler: --quick büyük tabloları belleğe almadan satır satır aktarır, --routines ve --triggers saklı yordamlarla tetikleyicileri de alır (bunlar unutulduğunda geri dönüşte uygulama sessizce bozulur), --default-character-set=utf8mb4 ise Türkçe karakterlerin soru işaretine dönmesini engeller. Dökümün eksiksiz olduğunu tek satırla doğrulayın: zcat yedek.sql.gz | tail -1 çıktısı -- Dump completed ile bitmelidir. Disk dolduğu için yarıda kesilmiş bir döküm, sıkıştırılmış halde gayet normal görünür.

Saklama takvimi

Her yedeği sonsuza kadar tutmak gereksiz maliyettir; yalnız son yedeği tutmak ise tehlikelidir. Fark edilmesi haftalar alan bir bozulmada geriye gidecek noktaya ihtiyaç duyarsınız. Dengeli bir takvim:

Bu takvimi elle tutmak zordur; saklama kurallarını uygulayan bir araç kullanın. Sürüm tutan yedekleme araçlarında takvim tek satıra iner:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Bu tür araçların iki pratik faydası var: veriyi parçalara ayırıp tekrar edenleri bir kez sakladıkları için 30 günlük geçmiş, tam kopyaların toplamının çok altında yer kaplar; ve şifreleme istemci tarafında yapıldığı için yedek alanını işleten tarafın içeriği okuması mümkün olmaz.

Fidye yazılımı yedekleri de hedefler

Modern fidye yazılımlarının ilk işi erişebildiği yedekleri şifrelemek ya da silmektir. Sunucudan yazılabilir durumda bağlı duran bir yedek diski, saldırı anında yedek değildir. İki savunma:

• Çekme modeli: Yedek sunucusu üretim sunucusuna bağlanıp veriyi çeker. Üretim sunucusunun yedek alanına yazma yetkisi olmaz.
• Değişmez (immutable) saklama: Nesne depolamada saklama kilidi açıkken, yönetici bile belirlenen süre dolmadan dosyayı silemez.

Yedeklerin şifreli tutulması da ayrı bir gerekliliktir; şifreleme anahtarını yedeğin yanında saklamayın.

Provasız yedek, yedek değildir

Altı ayda bir, takvime koyarak şu tatbikatı yapın:

1. Rastgele bir yedek noktası seçin — en yenisini değil.
2. Boş bir sunucuya ya da yerel bir kaba tam geri dönüş yapın.
3. Süreyi kronometreyle ölçün ve not edin.
4. Siteyi açıp gerçekten çalıştığını doğrulayın: giriş yapın, bir kayıt oluşturun.
5. Eksik çıkan her şeyi yedek listesine ekleyin.

Bu provada en sık ortaya çıkan eksikler şunlardır: yedeklenmemiş bir yapılandırma dosyası, unutulmuş bir cron görevi, geri dönüşün beklenenden üç kat uzun sürmesi ve veritabanı kullanıcısının parolasının hiçbir yerde yazılı olmaması. Provayı bir taşıma tatbikatı gibi kurgulamak işi kolaylaştırır; kesintisiz taşıma yazısındaki adım sırası burada da işe yarar.

Sessiz başarısızlığı yakalayın

Yedekleme düzeneklerinin çoğu gürültüyle değil sessizce bozulur: parola değişir, disk dolar, bir dizin yeniden adlandırılır ve iş her gece "çalışmaya" devam eder. Dört basit kontrol bunu yakalar:

• Çıkış kodunu kontrol edin. Cron satırının sonundaki komut sıfırdan farklı bir kodla dönüyorsa haber alın; cron'un varsayılan davranışı sessiz kalmaktır.
• Son yedeğin yaşına eşik koyun. En yeni yedek 26 saatten eskiyse uyarı üretin. Bu tek kural, "aylardır yedek alınmıyormuş" vakalarının neredeyse hepsini engeller.
• Boyut sapmasına bakın. Dünkü yedek 4 GB, bugünkü 40 MB ise iş başarılı görünse bile içerik eksiktir.
• Bütünlüğü periyodik doğrulayın. Sürüm tutan araçlarda restic check --read-data-subset=5% gibi bir komut, deponun rastgele bir diliminde bozulma olup olmadığını okuyarak test eder.

3-2-1 ne zaman fazla, ne zaman yetersiz

Kural bir alt sınırdır, evrensel reçete değil. Tek sayfalık bir tanıtım sitesinde, içeriği bir depo deposunda (repository) duran ve dakikalar içinde yeniden kurulabilen bir projede üç kopya tutmak gereksiz maliyettir; kaynak kodu ve yapılandırma yeterlidir.

Öte yandan sipariş alan bir sistemde 3-2-1 yetmez. Günlük yedekle çalışan bir e-ticaret sitesinde akşam yaşanan bir arıza, o günün tüm siparişlerini siler. Bu senaryoda veritabanı için ikili kayıt (binlog) tabanlı zaman noktası kurtarma gerekir: gece alınan tam yedek üzerine, arıza anına kadar olan işlemler tekrar oynatılır. Aynı mantıkla, geri dönüşün altı saat sürdüğü bir düzenek RTO'su iki saat olan bir işletme için yetersizdir — kopyaların sayısı değil, dönüş süresi belirleyicidir.

Barındırma paketinizdeki yedek nedir, ne değildir?

Paylaşımlı paketlerde sağlanan haftalık yedek, sunucu tarafındaki felaket senaryolarına karşı bir güvenlik ağıdır; sizin yedekleme stratejinizin yerine geçmez. Kendi kopyanızı kendi kontrolünüzdeki bir alanda tutun. Fiziksel sunucu ve VDS kullanıyorsanız harici bir yedekleme alanı almak, kaybedilen bir günün maliyeti yanında önemsiz bir kalemdir.

Yedekleme kurulduktan sonra izlemeyi de bağlayın: yedek işi başarısız olduğunda haber almıyorsanız, aylarca boş klasöre yedek aldığınızı ancak felaket gününde öğrenirsiniz. Sunucu izleme yazısında hangi eşiklerin uyarıya bağlanacağını anlattık.