Açık söyleyeyim: hiç geri yüklemediğiniz bir yedek, yedek değildir — kumardır. Her sabah yedekleme işinin başarı durumunu düzenli kontrol eden ama o yedeklerden tek bir dosyayı bile geri yüklememiş adminlerin bulunduğu ortamlar gördüm. Sonuç hep aynıdır: felaket geldiğinde "başarılı" yedek bozuk, eksik veya kritik bir bileşenden yoksun çıkar. Düzenli geri yükleme testi yapmıyorsanız, kurtaramayacağınız veri depoluyorsunuz demektir.
Bunu daha önce sessiz veri kaybı senaryoları hakkındaki yazımda (https://furkanikkan.com/urun/geri-yuklemede-basarisiz-olan-yedekler-sessiz-veri-kaybi-senaryosu-27) değinmiştim ama bu kez teoride kalmayıp tatbikatın gerçek sürecine inmek istiyorum.
Yedek Başarı Raporları Neden Yalan Söyler
Çoğu yedekleme aracı başarı raporlamasında cömerttir. Veeam, snapshot alındığında ve veri repository'e taşındığında "Success" der. Bacula işin 0 hatayla bittiğini söyler. Ama işte o raporların size söylemediği şeyler:
- Uygulamanın geri yüklenen veriden gerçekten başlayıp başlayamayacağı
- Yedeğin transaction loglarını mı yakaladığı yoksa sadece veri dosyalarını mı içerdiği
- Geri yüklemenin farklı donanımlı başka bir hostta çalışıp çalışmayacağı
- Şifreleme anahtarlarının hala erişilebilir ve süresi dolmamış olması
- Yedek zincirinin gerçekten tam mı yoksa bir incremental eksik mi olduğu
Bunu bir PostgreSQL sunucusunda zor yoldan öğrendim. Yedekleme işi 14 gün üst üste başarı raporladı. Geri yüklememiz gerektiğinde, WAL arşivlemesinin bir yapılandırma değişikliğinden sonra sessizce durduğu ortaya çıktı. Base yedek iyiydi ama yalnızca base yedeğin alındığı ana kadar kurtarabildik — tam bir haftalık transaction kaybettik. Başarı raporu teknik olarak doğruydu. Sadece gerçekten bilmemiz gereken şeyi söylemiyordu.
Üretimde Geri Yükleme Testini Nasıl Yapılandırıyorum
Her sistemin risk seviyesine uyan bir takvimle geri yükleme testleri çalıştırıyorum. Ortamımda kullandığım kabaca dağılım şöyle:
- Kritik veritabanları (PostgreSQL, MSSQL): Haftalık test instance'ına tam geri yükleme, artı günlük otomatik transaction log replay
- Dosya sunucuları: Aylık rastgele örnek dosya geri yükleme, kaynakla boyut kontrolü
- VM yedekleri: Aylık izole ağa tam VM geri yükleme, boot testi, servis kontrolü
- Active Directory / DNS: Üç aylık lab domain controller'a tam geri yükleme, replikasyon metadatasını doğrulama
- Web sunucuları (Nginx yapılandırmaları, uygulama dosyaları): Aylık geri yükleme + reload öncesi config syntax kontrolü
Buradaki anahtar kelime "izole". Asla üretim ağına geri yükleme yapmazsınız. Üretim subnetlerine rotası olmayan özel bir VLAN kullanıyorum. Geri yüklenen VM eski ağ yapılandırmasına sahipse veya bir domain controller'a ulaşmaya çalışırsa, izole ortamda güvenli şekilde başarısız olmalı — gerçek ağda kaosa yol açmamalı.
Pratik Bir Geri Yükleme Tatbikatı: PostgreSQL Örneği
Benim için gerçek haftalık PostgreSQL geri yükleme tatbikatı şöyle görünüyor. Basit ve betikleştirilmiş tutuyorum ki her seferinde aynı şekilde çalışsın.
# On the test restore host
export PGPASSWORD=$RESTORE_TEST_PASS
# Drop and recreate the test database
dropdb --if-exists -h localhost restore_test_db
createdb -h localhost restore_test_db
# Restore from the latest base backup
pg_restore -h localhost -d restore_test_db \
-j 4 --no-owner --no-privileges \
/backups/pg/base/latest.dump
# Replay WAL up to a specific timestamp
pg_ctl -D /var/lib/postgresql/restore_test \
-o "-c restore_command='cp /backups/pg/wal/%f %p'" \
-o "-c recovery_target_time='2024-01-15 14:30:00+03'" start
# Verify: count rows in a critical table
psql -h localhost -d restore_test_db -c \
"SELECT count(*) FROM orders WHERE created_at >= now() - interval '7 days';"Satır sayısı üretimin aynı dönemdeki değeriyle eşleşirse geri yükleme iyidir. Eşleşmezse, gerçek bir acil duruma dönüşmeden önce araştırmam gereken bir sorunum var. Her tatbikat sonucunu — tarih, veritabanı, satır sayısı, geçen süre — basit bir text dosyasına kaydederim. Şatafatlı değildir ama biri "yedeklerin çalıştığından emin miyiz?" diye sorduğunda grep'leyebileceğim bir geçmiş verir.
Her Geri Yükleme Testinin Yanıt Vermesi Gereken Üç Soru
Geri yükleme testi sadece dosyaları geri kopyalamakla ilgili değildir. Üç somut soruyu yanıtlamanız gerekir:
- Uygulama başlayabilir mi? Uygulama geri yüklenen dosyaları okuyamıyorsa işe yaramaz. Servisi başlatın, logları kontrol edin ve hatasız gerçekten başladığından emin olun.
- Veri noktası zamanla tutarlı mı? Point-in-time recovery yapıyorsanız, verinin hedeflediğiniz tam anı yansıttığını doğrulayın. Son kayıtlardaki timestamp'leri kontrol edin.
- Başkası da yapabilir mi? Geri yükleme sürecini bilen tek kişi tatildeyse, geri yükleme planınız yok demektir. Dokümante edin ve bir meslektaşınızın dokümantasyonu körü körüne takip ederek test etmesini sağlayın.
Geri Yükleme Testini Atladığınızda Ne Olur
Bunu kısa tutacağım çünkü sonucu birden fazla kez gördüm. Bir şirket kritik bir sunucuyu kaybeder. Admin aylardır yedeklerin çalıştığı için kendinden emindir. Geri yükleme başlar ve sonra:
- Yedek repository'si sessizce dolan bir volume üzerinde olduğu için son 3 yedek truncate edilmiş
- Şifreleme anahtarı az önce ölen aynı sunucuda saklanıyor
- Yedekleme yazılımı sürümü 2 ay önce yükseltilmiş ve eski yedek formatı yeni geri yükleme aracıyla uyumlu değil
- Kurulumu yapan kişi şirketten ayrıldığı için kimse geri yükleme komutunu bilmiyor
Bunların her biri önlenebilirdir. Ama bunları yalnızca geri yükleme testi yaparak bulursunuz.
Geri Yükleme Testi Kültürü Oluşturmak
Teknik kısım kolaydır. Zor olan, geri yükleme testini deadline'lardan ve personel değişikliklerinden sağ çıkacak bir alışkanlık haline getirmektir. Benim yaklaşımım:
- Takvimde yinelenen bir etkinlik olarak işaretleyin, "vaktim olduğunda" yapılacak bir görev değil
- Mümkün olduğunca otomatikleştirin — manuel test insanlar meşgulken atlanır
- Sonuçları takımla paylaşın ki herkes bir testin ne zaman başarısız olduğunu görsün
- Başarısız bir geri yükleme testine bir üretim incident'ı ile aynı aciliyetle yaklaşın
Ransomware müdahale kontrol listesinde (https://furkanikkan.com/urun/ransomware-mudahale-plani-ilk-60-dakika-kontrol-listesi-32) belirttiğim gibi, bir ransomware olayının ilk 60 dakikası containment ve değerlendirmedir. Ama yedekleriniz hiç test edilmediyse, o 60 dakikalık pencere hiç kurtarıp kurtaramayacağınızı bilmeceye dönüştürür.
Geri yükleme testi olmayan yedekler tiyatrodur. Gerçekten ihtiyaç duyduğunuz ana kadar kendinizi güvende hissettirirler. Tatbikatı çalıştırın. Bozuk yedeği saldırgan veya disk arızası bulmadan önce siz bulun.
Kapak görseli: cogdogblog · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/37996646802@N01/4158729317