Hiç Geri Yüklemediğiniz Yedek, Yedek Değildir

Bir yedeğin çalışmadığını keşfetmek için en kötü an, ona ihtiyaç duyduğunuz andır. Buna rağmen en yaygın senaryo tam olarak budur: yedekler bir kez yapılandırılır, dashboard'da on sekiz ay boyunca yeşil bir onay işareti görünür ve ardından restore işlemi boş bir veritabanı üretir.

Veritabanı yedeği restore işlemini test etmek, çoğu best practice'in isteğe bağlı olması anlamında bir best practice değildir. Yedek bir iddiadır ve bir yedeği restore edene kadar bu iddia test edilmemiş olarak kalır.

Yedeklerin nasıl başarısız olduğunu ve gerçek bir doğrulamanın neleri kontrol etmesi gerektiğini aşağıda bulabilirsiniz.

Bir yedeğin sessizce işe yaramaz hâle gelmesinin dört yolu

1. Boştur ve kimse kontrol etmemiştir

Yolun ortasında başarısız olan bir pg_dump yine de bir dosya üretebilir. Yanlış veritabanı adına karşı çalıştırılan bir dump, geçerli ve doğru, ancak boş bir dosya üretir. Exit code'un sıfırdan farklı olup olmadığını veya dosyanın mevcut olup olmadığını kontrol eden her şey için ikisi de başarılı görünür.

Dünyanın en ucuz kontrolü: boyutuna bakın ve dünküyle karşılaştırın. Dün 40 MB olan bir yedeğin 400 byte olması size gereken her şeyi söyler. Altı aydır 400 byte olan bir yedek ise bunu başından beri söylüyordur.

2. Veriyi içerir ama etrafındaki şeyleri içermez

Tek bir veritabanına uygulanan pg_dump, rolleri ve diğer veritabanlarını içermez. Yedeği yeni bir sunucuya restore ettiğinizde tablolar gelir, ancak her GRANT, mevcut olmayan bir role başvurur. Uygulamanız bağlanır ve her işlemde permission denied hatası alır.

Extensions da aynı sorundur. Şemanız pgcrypto veya uuid-ossp'ye bağlıysa ve hedefte bunlar yoksa restore işlemi yarıda başarısız olur ve elinizde bazı tablolar kalır.

3. İhtiyacınız olan restore işlemi için flag'ler yanlıştır

pg_dump, formata bağlı olarak farklı çıktılar üretir ve hata genellikle baskı altındayken fark edilir:

• Plain SQL, psql ile restore edilir ve insanlar tarafından okunabilir. Seçerek restore edilemez ve büyük veritabanlarında yavaştır.
• Custom format (-Fc), pg_restore ile restore edilir, parallelism ve selective restore desteği sunar ve kayda değer boyuttaki her şey için istediğiniz formattır.

Tutorial öyle yaptığı için plain format'ta yedek almak ve ardından bir olay sırasında tek bir tabloyu restore edemediğinizi fark etmek, oldukça spesifik ve önlenebilir bir kötü gün türüdür.

4. Şifresini çözemiyorsunuzdur

Yedekler encrypted ise — ki öyle olmalıdır — key yedeğin bir parçasıdır. Yalnızca kaybolan makinede bulunan veya yalnızca çalışmayan servisin environment variable'ında tutulan bir key, ihtiyaç duyduğunuz anda sahip olmadığınız bir key'dir.

Gerçek bir doğrulama nasıl görünür?

Test, "dosya mevcut mu?" sorusundan ibaret değildir. Dosyayı başka bir yere restore edin ve ona bir soru sorun.

# 1. Restore into a scratch database, not the live one
createdb verify_$(date +%Y%m%d)
pg_restore -d verify_$(date +%Y%m%d) --no-owner --no-privileges latest.dump

# 2. Ask it something only real data can answer
psql -d verify_$(date +%Y%m%d) -c "
  select
    (select count(*) from users)            as users,
    (select count(*) from orders)           as orders,
    (select max(created_at) from orders)    as newest_order;
"

# 3. Drop it
dropdb verify_$(date +%Y%m%d)

2. adım bütün amacın kendisidir. Hatasız tamamlanan bir restore işlemi, verilerin gerçekten orada olup olmadığı hakkında size yine de hiçbir şey söylemez. Satır sayıları ve güncellik kontrolü bunu gösterir.

Kontrol etmeye değer üç şey:

• Satır sayıları doğru büyüklük sırasındadır. Tam olarak aynı olmaları gerekmez — veriler değişir — ancak 200.000 satırlı bir tablonun şimdi 12 satıra düşmesi bir başarısızlıktır.
• En yeni kayıt günceldir. "Her gece alınan" yedeğinizdeki en yeni sipariş mart ayına aitse backup job mart ayında durmuş demektir.
• Uygulama gerçekten bağlanabilir. Bir staging instance'ını restore edilen veritabanına yönlendirin ve bir sayfa yükleyin.

Bunu resolution sırasında değil, bir takvime bağlı olarak yapın

Gerçekçi sıklık aylık ve automated olmalıdır; sonuç da fark edeceğiniz bir yerde tutulmalıdır. "Yedekleri test et" şeklinde bir calendar reminder, erteleyeceğiniz bir hatırlatmadır.

Bunun kalıcı olmasını sağlayan şey, başarısızlığı görünür hâle getirmektir: doğrulama query'si bir threshold'un altında satır döndürürse bu durum, production error'da olduğu gibi birini page etmelidir. Sessizce başarısız olan bir backup system, önem kazandığı ana kadar backup system olmamasından ayırt edilemez.

Dockup bunu nasıl ele alıyor?

Her biri yukarıdaki belirli bir başarısızlık türünü hedefleyen üç karar.

Yedekler başka bir yere gider. Veritabanıyla aynı diskte bulunan bir yedek, yedek değildir — diskle birlikte kaybolacak bir kopyadır. Dockup, veritabanı yedeklerini üretilirken doğrudan object storage'a stream eder; böylece dosya, onu oluşturan host'a hiçbir zaman bağımlı olmaz.

Encrypted'dırlar ve key makinede tutulmaz. Yedekler stream edilirken AES-256-GCM ile encrypted hâle getirilir. Recovery açısından önemli nokta, key'in yedeklenen servisin environment'ında tutulmak yerine platform tarafından saklanmasıdır.

Hiçbir şey üretmeyen bir işlem yedek olarak kaydedilmez. Bu yaklaşım, boş dosya sorununu doğrudan ele alır: dump işlemi sıfırdan farklı bir exit code ile tamamlanırsa veya sıfır byte üretirse upload silinir ve yedek failed olarak kaydedilir. Sonuçta, içlerinden birinin 400 byte'lık dosya olduğu yeşil kayıtlarla dolu bir listeniz olmaz.

dockup db backup my-project/main-db --json     # take one now
dockup db backups my-project/main-db --json    # list them with sizes

Bu listedeki boyutlar, sahip olduğunuz en ucuz health check'tir. Trendlerini izleyin.

Rahatsız edici soru

Production veritabanınız önümüzdeki on dakika içinde yok edilseydi onu ne kadar sürede geri getirirdiniz ve ne kadar veri kaybederdiniz?

Her iki sayıyı da yanıtlayamıyorsanız bir backup strategy'niz yok — backup file'larınız var. Aradaki fark tamamen birinin daha önce restore işlemini yapıp yapmadığıyla ilgilidir.

Sık sorulan sorular

Bir restore işlemini ne sıklıkta test etmeliyim? Aylık, manual yerine automated bir yaklaşım için makul bir varsayılandır. Önemli olan sıklığın agresif olması değil, başarısızlığın görünür hâle gelmesidir.

Restore işlemi tamamlandığı hâlde neden veri oluşmadı? Genellikle dump yanlış veritabanına karşı alınmıştır veya dosya yazılırken yolun ortasında başarısız olmuştur. Yedek boyutlarını zaman içinde karşılaştırın — boş bir dump, boyut trendinde açıkça görülür ve status column'ında görünmez.

Yedekler encrypted olmalı mı? Evet ve key, makinenin kaybedilmesine dayanacak bir yerde tutulmalıdır. Key'i kaybolan sunucuda bulunan encrypted bir yedek kurtarılamaz.

Snapshot ile yedek aynı şey midir? Hayır. Bir volume snapshot, veritabanının o anda içinde bulunduğu durum da dâhil olmak üzere diski yakalar. Logical dump ise yapısı gereği tutarlıdır. Çoğu ekip, farklı arıza türleri için her ikisini de kullanmak ister.