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.

Uygulamalı örnek: restic ile şifreli, sürümlü yedek ve geri dönüş provası

3-2-1 kuralını kâğıttan sunucuya taşımanın en kısa yollarından biri restic'tir: açık kaynaklıdır, yedekleri baştan şifreler, aynı veriyi ikinci kez saklamaz ve yerel diskten nesne depolamaya kadar pek çok hedefe yazabilir. Aşağıdaki adımları bir deneme sunucusunda, 500 dosya ve bir veritabanı dökümünden oluşan küçük bir site üzerinde uyguladık.

1. Depoyu oluşturun ve ilk yedeği alın

export RESTIC_REPOSITORY=/srv/yedek-depo
export RESTIC_PASSWORD_FILE=/root/.restic-parola
restic init
mysqldump --single-transaction sitedb > /srv/site/sitedb.sql
restic backup /srv/site --tag gunluk

Depo parolası kaybolursa yedekler de kaybolur; restic init bunu açıkça uyarır. Parolayı sunucunun dışında, ayrı bir yerde de saklayın. İlk yedek yaklaşık 29 MB veriyi okudu ve sıkıştırmayla depoya 21,7 MB yazdı. Ardından tek bir dosyayı değiştirip yedeği tekrarladık; ikinci çalıştırma tüm dosyaları yine taradı ama depoya yalnız 25 KB ekledi. Her yedek tam bir anlık görüntü gibi geri yüklenebilir, ama yalnız değişen parçalar yer kaplar. Günlük yedek almayı ucuzlatan budur.

2. Saklama takvimini komuta çevirin

Yazının başındaki saklama takvimi tek satırdır:

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

Bu komut 7 günlük, 4 haftalık ve 6 aylık anlık görüntüyü tutar, gerisini siler ve artık hiçbir anlık görüntünün kullanmadığı verileri depodan temizler.

3. Depoyu denetleyin ve geri dönüşü prova edin

restic check
restic restore latest --target /tmp/geri
diff -r /srv/site /tmp/geri/srv/site && echo "birebir"

restic check deponun yapısal bütünlüğünü doğrular; bizim denememizde "no errors were found" döndü. Ama asıl prova ikinci ve üçüncü satırdır: yedeği gerçekten ayrı bir yere açıp kaynakla karşılaştırmak. Denemede 503 dosya ve dizin geri geldi ve diff hiçbir fark bulmadı. Veritabanı dökümünü ayrıca boş bir veritabanına yükleyip birkaç tablonun satır sayısını kontrol edin; dosya yedeği tutarlı olsa da döküm yarım kalmış olabilir.

Fidye yazılımına karşı: sunucu kendi yedeğini silememeli

Yukarıdaki örnek, kuralın "1" ayağını karşılamaz: depo aynı sunucudadır. Uzak kopyada asıl soru, sunucuyu ele geçiren birinin yedekleri de silip silemeyeceğidir. restic'in kendi uzak sunucusu rest-server bu yüzden --append-only kipini destekler: istemci yeni yedek ekleyebilir ama var olanları silemez; eski anlık görüntüleri temizleme işi yalnız yedek sunucusu tarafında, ayrı bir yetkiyle yapılır. Nesne depolamada aynı sonucu sürümleme ve nesne kilidi verir. Hangisini seçerseniz seçin ilke aynıdır: yedek alan sunucunun kimlik bilgileri, yedeği yok edemeyecek kadar dar olmalı.

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.

Sık sorulan sorular