Hiç geri yüklenmemiş yedek, yedek sayılmaz: haftanın üç aracı

Aynı hafta PostgreSQL yedekleriyle ilgili üç haber ve bir Camunda sürümü çıktı; dördü de aynı şeyi söylüyor: kimsenin açmadığı kopya koruma sayılmaz. Müşteri sunucularını 2022'den beri yönetiyorum ve ben de böyle düşünüyorum. İşletme sahibinin bütün bunlardan alacağı tek şey, yükleniciye soracağı bir soru: veritabanı kopyası en son ne zaman geri yüklendi ve ne kadar sürdü.

Neler yayımlandı

PostgreSQL News 22 Ekim'de BackupDrill duyurusunu yayımladı. Araç Supabase'deki veritabanından pg_dump alıyor, arşivi sağlama toplamıyla birlikte sizin S3 uyumlu bucket'ınıza koyuyor, sonra backupdrill drill komutuyla son kopyayı tek kullanımlık bir PostgreSQL konteynerinde açıp kontrol ediyor: arşiv sağlam mı, pg_restore tamamlandı mı, indeksler ve kısıtlar oluşturuldu mu, bütün tablolar yerinde mi, veri olan tablolar boş değil mi. Geri yükleme süresi kaydediliyor. CLI MIT lisanslı; takvimle çalışan ücretli bir servis ve ücretsiz planı var. Şimdilik yalnızca Supabase için.

Aynı gün aynı yerde PostgreSQL 13 ve üzeri için SafeGrd çıktı. Daemon veritabanının yanında duruyor, salt okunur bir rolle bağlanıyor, kopyayı daha sizin host'unuzdayken age anahtarıyla şifreliyor ve Object Lock açık bir S3 bucket'a yazıyor. Kontrole Fire Drill diyorlar: kopya ya bellekte oynatılıp tablo, satır ve sütun sayısı alınırken kaydedilenle karşılaştırılıyor, ya da bir sandbox'a geri yükleniyor ve oraya kendi SQL kontrollerinizi ekleyebiliyorsunuz. Her kontrol imzalı bir kayıt bırakıyor, kayıtlar zincir halinde birbirine bağlı. Tek veritabanı için ücretsiz plan: günde bir kopya, haftada bir bellekte kontrol; ücretli planlar ayda 15 dolardan başlıyor.

Biraz daha önce, 18 Ekim'de, pgBackRest 2.60.0 çıktı. Davranıştaki ana değişiklik: geri yüklenen dosyada sayfa sağlama toplamı yanlışsa geri yükleme artık hatayla duruyor; expire komutu ise kalan kopyaların en eskisinde böyle hatalar varsa eski kopyaları silmeyi reddediyor. Bu, checksum-page-error=n seçeneğiyle kapatılıyor.

Camunda 19 Ekim'de 8.10 Self-Managed sürümünde kümenin geri yüklenmesini anlattı. Eskiden broker'lar durduruluyor, dizinler elle temizleniyor ve ayrı bir uygulama çalıştırılıyordu; şimdi birkaç REST API çağrısı: kümeyi RECOVERING moduna almak, depolamayı geri yüklemek, kopya ID'siyle POST /v2/restore çağırmak. Hoşuma giden ifadeleri şu: kimsenin uygulamadığı bir kurtarma planı plan sayılmaz, tahmin sayılır. Üç ayda bir gece kopyasını kimsenin bağlı olmadığı bir kümeye açıp süreyi ölçmeyi öneriyorlar.

İşletme için ne anlama geliyor

Dört yıllık talepleri, teklifleri ve arama geçmişi veritabanında duran bir servis şirketini ele alalım. Yüklenici “yedekler her gece alınıyor” diyor. Pazartesi sanal makinenin diski ölüyor. Kopyalar var, ama son çalışan kopya üç haftalık çıkıyor: kopyalama görevi bir ay önce bir tabloda düşmeye başlamış ve bunu kimse görmemiş. Üç haftalık talepler e-postalardan ve yöneticilerin hafızasından toplanıyor.

Güvenceyi yalnızca birinin yakın zamanda, ayrı bir makinede yaptığı ve ardından ana tablolardaki satırları saydığı geri yükleme verir. Haftanın dört haberi de bu adımın takvime nasıl konacağını anlatıyor.

Bende nasıl çalışıyor

Projelerimin neredeyse hepsinde MariaDB var, PostgreSQL değil; bu yüzden BackupDrill ve SafeGrd bana doğrudan uymuyor ve ikisini de kendim denemedim. İlke aynı, araçlar kendi araçlarım.

ABD'deki PDR şirketiyle 2021'den beri çalışıyorum. 2022'de onlar için Google Cloud'da Debian üzerinde bir sunucu kurdum ve o zamandan beri kendim yönetiyorum: sunucu, VPN, ağ donanımı ve telefon sistemi. Sistemin birkaç koruma ve yedekleme katmanı var. 2022'den beri geri yükleme gerektiren ciddi bir arıza olmadı. Bunu şans saymıyorum: kopyalar var ve hangisinin açıldığını biliyorum.

2023'ten beri sunucusundan ve ağından sorumlu olduğum hidroponik çiftlikte MariaDB veritabanı, sunucuyla aynı Debian sanal makinesinde duruyor; oraya iki sahadaki 25 kontrolörden veri geliyor. Orada veritabanını kaybetmek, başka bir ekibin otomasyonu üzerine kurduğu ölçüm geçmişini kaybetmek demek.

“Birlikte Kahve” adlı şirket içi servisin çalıştığı stüdyo sunucusunda SQLite veritabanı bir Docker volume'unda duruyor. Sunucu ortak ve 2 GB belleği var, bu yüzden kopyayı orada şöyle kontrol etmek pratik: yanına bir konteyner kalkıyor, kopyayı okuyor ve kapanıyor. Geri yükleme süresiyle ilgili rakam yayımlamıyorum.

Ben ne yapardım

Yükleniciye kopyaların nerede durduğunu ve en son ne zaman birinin açıldığını sorun. “Otomatik alınıyor” cevabı sayılmaz.

Bir gün belirleyin. Ayda bir kopya ayrı bir konteynere açılır ve biri üç-beş ana tablodaki satır sayısını karşılaştırır: talepler, müşteriler, belgeler. SafeGrd gibi siz de “müşterisi olmayan kaç anlaşma var” türünden kendi sorgularınızı ekleyebilirsiniz.

“Geri yüklüyoruz” kararından çalışan sisteme kadar geçen süreyi ölçün. Gerçek kurtarma süreniz bu. Sözleşmede yazanla karşılaştırın.

Kopyaları veritabanının olduğu yerde tutmayın. Ayrı bir bucket ya da başka bir sunucu; ve yazmada kullanılan anahtarla silinemesinler. SafeGrd Object Lock'u tam bunun için kullanıyor.

Sonucu kaydedin: tarih, kim kontrol etti, ne kadar sürdü, ne tutmadı. Bir yıl sonra bu kayıtlardan veritabanının kurtarma planından daha hızlı büyüyüp büyümediği görünür.

Sistemin neden ortak bir veri merkezine ihtiyacı olduğunu ve bunun arızaları nasıl atlatması gerektiğini Sunucu: veri, erişim ve sürecin yürütülmesi yazısında anlattım; işletme yaklaşımı yayınlanabilen ve geri yüklenebilen altyapı sayfasında toplu halde. Projeler: PDR şirketinin teknik ortağı ve hidroponik çiftliğin sunucusu ve ağı. Aynı konuda: dünya kritik bir açığı yamarken sunucuları nasıl kontrol ediyorum ve tek sunucuda yapay zeka nöbetçiye ne bırakırdım. Daha önce kopyanın ancak doğrulanmış geri yüklemeden sonra koruma olduğunu ve dağıtım saklama süresinin kurtarma planıyla örtüşmesi gerektiğini yazmıştım. Veritabanınızın geri yüklenip yüklenmeyeceğini bilmiyorsanız nerede durduğunu anlatın: Görevi konuşalım.