Gerçekten Geri Yüklenebilen Veritabanı Yedekleme Zamanlaması
22 Eylül 2026 tarihinde yayımlandı
Bir veritabanı sabah 9:00'da tamamen sağlıklı görünebilir. ve buna rağmen 8:45'te yapılan siparişleri, müşteri kayıtlarını veya uygulama değişikliklerini kurtarmanızı imkânsız hâle getirebilir. Veritabanı yedekleme zamanlamasının kontrol etmesi gereken boşluk tam olarak budur. Bir yedekleme planı sadece gece çalışan bir iş değildir. Tanımlanmış veri kaybı sınırları, geri yükleme süreleri, saklama kuralları ve bir şey sessizce çalışmayı bıraktığında uyarı üretimi olan bir kurtarma planıdır.
Küçük işletme web sitesi, ajans platformu veya büyüyen bir SaaS uygulaması için doğru zamanlama; verinin ne kadar hızlı değiştiğine ve bir kaybın ne kadar maliyetli olacağına bağlıdır. Broşür niteliğindeki bir site günlük yedeklemeyi tolere edebilir. Yoğun bir mağaza veya işlemsel uygulama ise genellikle edemez. Hizmet ancak kurtarma noktası bilindiğinde sakindir.
Takvimle Değil, Kurtarma Hedefleriyle Başlayın
Saatlik, günlük veya haftalık yedeklemeleri seçmeden önce iki pratik hedef belirleyin: Recovery Point Objective (RPO) ve Recovery Time Objective (RTO).
RPO rahatsız edici bir soruya yanıt verir: işletme ne kadar yakın tarihli veriyi kaybetmeyi göze alabilir? RPO'nuz dört saatse, yedekleme ve günlük stratejiniz veriyi en fazla dört saatlik bir noktaya geri yüklemenize imkân vermelidir. Tüm gün sipariş alan bir e-ticaret veritabanı için dört saat bile fazla olabilir. Az değişen bir iç araç için bu makul olabilir.
RTO bir sonraki soruya yanıt verir: kurtarma gerçekleşirken uygulama ne kadar süre kullanılamaz kalabilir? 5 GB'lık bir veritabanını geri yüklemek ile 2 TB'lık bir veritabanını geri yüklemek aynı şey değildir; özellikle dizinlerin yeniden oluşturulması gerekiyorsa, verinin uzak depolamadan aktarılması gerekiyorsa veya bağımlı birkaç hizmetin sırayla geri dönmesi gerekiyorsa.
Zamanlamaya bu hedefler karar verir. Ayrıca yaygın bir sahte rahatlığı da önlerler: var olan ama işletmenin gerçekte sahip olduğu sürede geri yüklenemeyen bir yedekleme.
Pratik Bir Veritabanı Yedekleme Zamanlama Modeli
Çoğu üretim veritabanı, gecelik tek bir büyük dump yerine katmanlı bir zamanlamadan fayda görür. Kullanılan araçlar MySQL, MariaDB, PostgreSQL, Microsoft SQL Server ve yönetilen veritabanı platformları arasında farklılık gösterir, ancak çalışma ilkesi aynı kalır: geri yüklenebilir temel yedeklemeleri sık işlem düzeyinde korumayla birleştirin.
Birçok iş yükü için mantıklı bir düzen; günlük tam yedekleme, daha sık artımlı veya diferansiyel yedeklemeler ve veritabanı destekliyorsa sürekli işlem günlüğü arşivlemesini içerir. PostgreSQL write-ahead logs (WAL) kullanır; MySQL ve MariaDB ise yaygın olarak binary logs kullanır. Bu günlükler belirli bir zamandaki noktaya kurtarmaya imkân verir; yani veritabanını yanlışlıkla silmeden, hatalı dağıtımdan veya bozuk içe aktarımdan hemen önceki hâline geri yükleyebilirsiniz.
Örneğin küçük bir çevrimiçi mağaza her gece tam yedekleme alabilir, binary logs'u sürekli tutabilir ve birkaç haftalık kurtarma noktalarını saklayabilir. Bir yönetici saat 2:17 p.m.'de yanlış SQL ifadesini çalıştırırsa, kurtarma hedefi önceki gece yerine 2:16 p.m. olabilir. Bu fark çok uzun bir öğleden sonrayı kurtarabilir.
Daha az değişen bir pazarlama sitesi, haftalık arşiv kopyasıyla günlük veritabanı yedeklemeleri kullanabilir. Aktif kullanıcıları olan bir SaaS platformu günlük tam yedeklemelere, birkaç dakikada bir log shipping'e ve replika ya da ek erişilebilirlik önlemlerine ihtiyaç duyabilir. Yedeklemeler yüksek erişilebilirliğin yerini tutmaz ve yüksek erişilebilirlik de yedeklemelerin yerini tutmaz. Replikasyon bir hatayı çok verimli şekilde kopyalayabilir.
Zamanlamayı İş Yüküyle Eşleştirin
Veritabanı etkinliği her zaman sabit değildir. Bir ajans, mesai saatlerinde müşteri güncellemeleri görebilir ama gece neredeyse hiç değişiklik olmayabilir. Bir rezervasyon platformu haftanın büyük bölümünde sakin olabilir, ardından cuma günü çok yoğunlaşabilir. Mümkünse tam yedeklemeleri daha düşük etkinlik dönemlerinde zamanlayın, ancak sessiz bir pencerenin işi zararsız kıldığını varsaymayın.
Tam yedeklemeler disk G/Ç'si, CPU, ağ bant genişliği ve veritabanı kaynaklarını tüketebilir. Yoğun bir VPS veya dedicated server üzerinde, plansız bir yedekleme süreci gerçek müşteri trafiğiyle yarışabilir. Kilitlemeyi en aza indiren yedekleme yöntemleri kullanın, gerektiğinde aktarımları kısıtlayın ve ilk çalıştırmalar sırasında sistem metriklerini izleyin. CPU yükü, disk gecikmesi, boş depolama alanı ve yedekleme süresi gerçek hikâyeyi anlatır.
Yedekleme süresi bir sonraki planlı yedeklemeyle çakışmaya başlıyorsa, zamanlamaya dikkat edilmesi gerekir. Kapasite gözden geçirilmeden sıklığın artırılması, teknik olarak zamanlanmış ama operasyonel olarak gecikmiş bir yedekleme işleri kuyruğu oluşturabilir.
Saklama, Yedekleme Maliyetleri ile Riskin Buluştuğu Yerdir
Saklama olmadan bir zamanlama eksiktir. Her yedeği sonsuza kadar tutmak pahalı ve yönetilmesi zor hâle gelir. Yedekleri çok erken silmek, bozulma veya yetkisiz değişiklikler haftalar sonra fark edildiğinde küçük bir sorunu kalıcı kayba dönüştürür.
Kullanışlı bir saklama politikası genellikle birkaç zaman ufkunu korur. Yakın tarihli geri yükleme noktaları sık olmalıdır çünkü operasyonel hatalar için en çok bunlara ihtiyaç duyulur. Günlük yedeklemeler önceki haftalar için kapsama sağlarken, haftalık veya aylık arşivler daha eski sorunlara, denetimlere veya veri hasarının geç fark edilmesine karşı koruma sağlar.
Doğru saklama süresi; işletmenize, sözleşmesel taahhütlerinize ve uyumluluk ihtiyaçlarınıza bağlıdır. Bir geliştirici staging veritabanı yalnızca kısa bir geçmişe ihtiyaç duyabilir. Müşteri verileri, finansal işlemler veya düzenlemeye tabi kayıtlar çok daha uzun saklama süreleri ve daha sıkı erişim kontrolleri gerektirebilir. Sadece profesyonel görünüyor diye başka bir işletmenin saklama politikasını kopyalamayın.
Ayrıca yedekleme zincirlerinin gizli boyutunu da hesaba katın. Artımlı yedeklemeler ve işlem günlükleri, temel yedeklemenin erişilebilir kalmasına bağlıdır. Gerekli bir tam yedekleme erken kaldırılırsa, sonraki artımlı dosyalar işe yaramaz olabilir. Otomatik saklama bu bağımlılıkları anlamalı, bir klasördeki en eski dosyayı basitçe silmemelidir.
Yedekleri Veritabanı Sunucusundan Uzakta Saklayın
Yalnızca aynı sunucuda saklanan bir yedekleme küçük bir hata için faydalıdır, ancak sunucu kaybına, depolama arızasına, ransomware'e veya ciddi bir yapılandırma olayına karşı zayıf bir korumadır. Bağımsız kimlik bilgileri ve erişim kontrolleri olan ayrı depolamada en az bir şifreli kopya bulundurun.
Bu, her yedekleme işlemini büyük bir kurumsal projeye dönüştürmeyi gerektirmez. Ancak hata alanlarını ayırmayı gerektirir. Bir VPS diski erişilemez hâle gelirse, veritabanı ile onun tek yedeği birlikte ortadan kaybolmamalıdır. Kritik sistemler için, sunucu erişimi olan bir saldırganın son adım olarak yedekleri basitçe silememesi amacıyla ek bir immutable veya yazma korumalı kopyayı değerlendirin.
Şifreleme hem aktarım sırasında hem de beklemede önemlidir. Yedekleme dosyaları genellikle canlı veritabanıyla aynı hassas verileri içerir; buna müşteri ayrıntıları, hesap kayıtları veya uygulama sırları dahildir. Depolama hedefini koruyun, veriyi kimlerin geri yükleyebileceğini sınırlayın ve operasyonel gereksinimleriniz bunu gerektiriyorsa erişimi kaydedin.
Başarılı Bir Yedekleme Henüz Başarılı Bir Geri Yükleme Değildir
Doğrulama olmadan yeşil görünen yedekleme durumu en tehlikeli olandır. Bir iş tamamlanabilir ama eksik bir dump üretebilir, günlükleri atlayabilir, yanlış kimlik bilgileri kullanabilir veya daha sonra çözülemeyecek dosyalar yazabilir. Günlükler neşeli görünebilir. Geri yükleme ise o kadar neşeli olmayacaktır.
Tanımlı bir zamanlamaya göre geri yükleme testleri yapın. Kritik bir uygulama için, en az aylık olarak ve veritabanı sürümü, yedekleme araçları, şifreleme anahtarları veya depolama kurulumunda anlamlı değişikliklerden sonra test edin. Üretimi etkilemeden satır sayılarını, uygulama başlangıcını, kullanıcı erişimini ve temel iş akışlarını doğrulayabilmeniz için geri y üklemeyi izole bir ortama yapın.
Gereken süreyi ölçün. Bir geri yükleme testi size umutlu bir tahmin yerine RTO'nuz için kanıt sağlar. Ayrıca gözden kaçan bileşenleri de ortaya çıkarabilir: yüklenen dosyalar, nesne depolama, yapılandırma değerleri, veritabanı kullanıcıları, uzantılar veya arka plan çalışanları. Tek başına geri yüklenen bir veritabanı doğru olabilir ama yine de uygulamayı çevrimiçi duruma geri getirmeyebilir.
Yedekleme Zincirini Bir Üretim Hizmeti Gibi İzleyin
Yedekleme işleri için uyarı gerekir, yalnızca zamanlama değil. Başarısız işler, beklenen yedekleme dosyalarının eksikliği, gecikmiş log shipping, yetersiz depolama, checksum hataları ve yedekleme boyutu veya süresindeki olağan dışı değişiklikler için uyarı üretin. Bir yedekleme aniden çok daha küçük hâle gelirse bu geçerli bir veri azalması olabilir, ama aynı zamanda bir tablonun hariç tutulduğu veya işin erken çıktığı anlamına da gelebilir.
İzleme, kurtarmaya ihtiyaç duyulmadan önce sorumlu kişiyi haberdar etmelidir. Günlük raporlar faydalıdır, ancak başarısızlıklar için uygulanabilir uyarılar daha iyidir. Mümkün olduğunda operasyonel panolara yedekleme yaşını ve en son doğrulanmış geri yükleme noktasını ekleyin. Bu, olay sırasında ekiplere net bir yanıt verir: elde ne var ve ne kadar güncel?
Yönetilen altyapıda zincirin her parçasından kimin sorumlu olduğunu doğrulayın. Taraflardan biri sunucuyu, diğeri veritabanı uygulamasını, bir başkası da yedekleme depolama hesabını yönetebilir. Sorumluluk boşlukları mümkün olan en kötü zamanda, genellikle bir geri yükleme talebi sırasında ortaya çıkar. kodu.cloud'da bu, herkesin hâlâ kahvesi ve sabrı varken erkenden netleştirmeye değer bir operasyonel ayrıntı türüdür.
Zamanlamayı Belgelendirin ve Bilinçli Şekilde Değiştirin
Yedekleme türünü, çalıştırma sıklığını, depolama hedefini, saklama süresini, şifreleme yöntemini, geri yükleme prosedürünü, RPO'yu, RTO'yu ve uyarı alıcılarını belgelendirin. Kimlik bilgilerini ve kurtarma anahtarlarını bir dağıtım betiğinin içinde veya birinin özel notlarında değil, onaylı güvenli sistemlerde saklayın.
Uygulama büyümesinden, yeni veri entegrasyonundan, büyük bir veritabanı yükseltmesinden veya müşteri taahhütlerindeki bir değişiklikten sonra planı gözden geçirin. Altı ay önce gecelik yedekleme penceresine düzgünce sığan veritabanı artık log tabanlı kurtarma ve daha fazla depolama kapasitesi gerektiriyor olabilir. Bu, normal büyümedir; orijinal planın başarısızlığı değildir.
Faydalı hedef basittir: ne kadar geriye gidebileceğinizi, bunun ne kadar süreceğini ve talep geldiğinde kimin ne yapacağını bilin. Veritabanı yedekleme zamanlamasını bu yanıtların etrafında kurun, bunları düzenli olarak test edin; böylece siz dinlenirken sunucularınız sessiz işlerini sürdürmeye devam edebilir.
Andres Saar Müşteri Hizmetleri Mühendisi