Zamanda Noktasal Kurtarma ve Snapshot'lar: Neleri Kaybedersiniz?

Birisi saat 16:15'te WHERE yan tümcesi olmadan bir DELETE çalıştırıyor. Elinizdeki en güncel yedek saat 03:00'ten. Bu iki zaman arasındaki her şey kayboluyor ve hiçbir geri yükleme işlemi onu geri getiremiyor.

Bu aralığın bir adı var: recovery point objective veya RPO. zamanda noktasal kurtarma ve snapshot'lar arasındaki seçim de tamamen bu aralığın ne kadar büyük olmasına razı olduğunuza bağlı.

İki model

Snapshot'lar, verilerinizin belirli bir andaki durumunu yakalar. Bir zamanlamaya göre, genellikle nightly olarak çalışırlar. Bir snapshot'ı geri yüklediğinizde, tam olarak alındığı andaki duruma dönersiniz; sonrasında gerçekleşen her şey kaybolur.

Zamanda noktasal kurtarma, bir temel yedeği veritabanının sürekli yazılan write-ahead log akışıyla birleştirir. Her değişiklik sırayla kaydedildiği için, saklanan log'un kapsadığı herhangi bir ana, hatta silme işleminden bir dakika önceki 16:14'e kadar yeniden oynatma yapabilirsiniz.

Aradaki fark kademeli değildir. Fark, "bir gün kaybettik" ile "bir dakika kaybettik" arasındaki farktır.

Kararı belirleyen sayı

Kendinize dürüstçe tek bir soru sorun: Son on iki saatte yazılan her şeyi kaybetseydiniz ne olurdu?

Kişisel bir proje, bir dokümantasyon sitesi veya verileri yeniden üretilebilen bir dahili araç için: pek bir şey olmaz. Nightly snapshot'lar gerçekten doğru seçenektir; sürekli arşivleme için ödeme yapmak israf olur.

Müşterilerin veri yazdığı her sistemde cevap genellikle "insanlara e-posta gönderip durumu açıklamamız gerekir" şeklindedir. Artık var olmayan siparişler. Kaybolan yüklemeler. Gönderilmiş ama artık mevcut olmayan mesajlar. Yalnızca destek maliyeti bile çoğu zaman altyapı harcamaları arasındaki bir yıllık farkı aşar.

Hata, snapshot'ları seçmek değildir. Hata, on iki saatlik bir boşluğun maliyetini hiç sormadan snapshot'ları varsayılan seçenek olarak belirlemektir.

Snapshot'ların gerçekten iyi olduğu alanlar

Snapshot'lar daha düşük seviyeli bir ürün değildir. PITR'nin kapsamadığı arızaları ele alırlar:

• Tüm diskin kaybı. Ayrı depolamadaki bir snapshot, veritabanının sahip olmadığı dosyalar da dahil olmak üzere her şeyi geri yükler.
• Hızlı, kaba geri alma. Staging ortamında başarısız olmuş bir migration'ı geri almak, bir log'u yeniden oynatmaktan snapshot ile daha hızlıdır.
• Maliyet. Günde bir kopya saklamak, her yazma işlemini saklamaktan daha ucuzdur.
• Basitlik. Daha az hareketli parça gerçek bir operasyonel avantajdır; özellikle küçük bir ekip için.

Tuzak, bunları sürekli yazma alan bir veritabanı için yeterli kabul etmektir.

PITR size neye mal olur?

Ücretsiz değildir ve maliyetleri açıkça belirtmek gerekir:

• Depolama. Temel yedeği ve retention window boyunca gerçekleşen her yazma işlemini saklarsınız.
• Karmaşıklık. Arşivlemenin sürekli çalışması gerekir. Bir hafta boyunca sessizce başarısız olan bir archiver, kurtarılabilir aralığınızın bir hafta önce sona erdiği anlamına gelir. Bu nedenle arşivi izlemek, onu yapılandırmak kadar önemlidir.
• Geri yükleme süresi. Bir log'u yeniden oynatmak, snapshot'ı geri yüklemekten daha uzun sürer. RPO'nuz iyileşir; RTO'nuz ise genellikle kötüleşir.

Son ödünleşim birçok kişiyi hazırlıksız yakalar. PITR daha az veri kaybetmeniz anlamına gelir; daha hızlı çevrimiçi olacağınız anlamına gelmez.

Ekiplerin çoğunun gerçekte ihtiyaç duyduğu katmanlı yanıt

Pratikte bu, iki seçenek arasında bir tercih değildir. Production veritabanları genellikle üç katmana ihtiyaç duyar; çünkü üç farklı şekilde arızalanırlar:

Snapshot'lar, günlük; bir veya iki hafta saklanır. Makineyi kaybetmeye karşı ucuz bir sigorta görevi görür. Aynı volume üzerinde bulunan veritabanı dışı dosyaları da bu katman korur.

Logical dump'lar, günlük; host dışında saklanır. Bir pg_dump, yapısı gereği taşınabilir ve tutarlıdır. Farklı bir major version'a, farklı bir sağlayıcıya veya bir laptop'a geri yüklenebilir. Sorun platformda, veride değilse istediğiniz şey budur.

Sürekli arşivleme, veritabanında müşteri verileri bulunduğunda. "Bugünü kaybettik" ifadesini "bir dakika kaybettik" ifadesine dönüştüren katmandır.

Her katman, diğerlerinin kapsamadığı bir durumu ele alır. Bir snapshot sağlayıcı değiştirmenize yardımcı olmaz. Logical dump, veritabanında bulunmayan bir dosyayı kurtarmanıza yardımcı olmaz. İkisi de dört saat önce yapılan bir silme işlemini geri almanıza yardımcı olmaz.

Dockup'ın konumu

Dockup, en yaygın arızaları kapsayan iki katmanı sunar ve bunların hangileri olduğunu netleştirmekte fayda vardır.

Volume snapshot'ları, isteğe bağlı olarak veya belirli sayıda retention ile zamanlanmış şekilde:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Logical database backup'ları, doğrudan object storage'a aktarılır ve aktarım sırasında şifrelenir:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

Bu ikinci yöntemin kurtarma açısından iki önemli özelliği vardır. Yedek hiçbir zaman database host'una yazılmaz; pg_dump çıktıyı üretirken doğrudan storage'a aktarır. Böylece geldiği diskle aynı kaderi paylaşmaz. Ayrıca non-zero ile sonlanan veya sıfır byte üreten bir dump silinir ve başarısız olarak kaydedilir; listede yedekmiş gibi görünmeye devam etmez.

Continuous archiving, bugün Dockup'ın sizin için çalıştırdığı bir özellik değildir. RPO'nuz gerçekten dakikalarla ölçülüyorsa, seçim yapmadan önce bunu bilmeniz gerekir. Managed database üzerinde bunu kendiniz çalıştırırken diğer her şey için platformu kullanmanız de makul bir yaklaşımdır.

Bu hafta yapmaya değer çalışma

Production veritabanınız için iki sayı yazın:

1. RPO — ne kadar veri kaybedebileceğiniz. Zamanla ölçülür.
2. RTO — ne kadar süre hizmet dışı kalabileceğiniz. Bu da zamanla ölçülür.

Ardından bir şeyi geri yükleyerek mevcut kurulumunuzun gerçekte ne sunduğunu kontrol edin. Yazdığınız sayılarla kurulumunuzun sunduğu sayılar farklıysa, hiçbir şey henüz alev almamışken vermeniz gereken bir karar bulmuşsunuz demektir. Karar vermek için en iyi zaman da budur.

Sık sorulan sorular

RPO ile RTO arasındaki fark nedir? RPO, kaybettiğiniz veri miktarıdır: kurtarılabilir son an ile arıza arasındaki boşluk. RTO ise kurtarmanın ne kadar sürdüğüdür. Snapshot'lar size büyük bir RPO ve kısa bir RTO sunar; PITR ise bunu tersine çevirir.

Bir saat önce silinen satırları nightly snapshot'tan kurtarabilir miyim? Hayır. Bir snapshot, alındığı andaki durumu geri yükler. Ondan sonra yazılan hiçbir şey dosyada bulunmaz. Rastgele bir anı kurtarmak için continuous archiving gerekir.

Volume snapshot ile database backup aynı şey midir? Hayır. Snapshot, veritabanının yazma işleminin ortasında sahip olduğu durum da dahil olmak üzere diski yakalar. Logical dump kendi içinde tutarlıdır ve farklı version'lara ve sağlayıcılara taşınabilir. Çoğu production kurulumu ikisini de kullanır.

Yedekleri ne kadar süre saklamalıyım? Bir sorunu fark etmenize yetecek kadar uzun süre. Corruption veya hatalı bir migration çoğu zaman günler sonra fark edilir. Bu nedenle yalnızca bir günlük retention'a sahip olmak, çoğu zaman elinizdeki tek yedeklerin zaten hasarı içerdiği anlamına gelir.