Yedek bir sorudur. Geri yükleme yanıtlar.

İlk tatbikatı bilinçli olarak küçük tutun

Bu tatbikat bir oyuncak notlar veritabanı ve bir ek oluşturur, her ikisini yakalar, ardından yeni bir veritabanına ve dizine geri yükler. PostgreSQL 17 sunucusu ve uyumlu istemci yardımcı programları, Bash ve GNU coreutils içeren tek kullanımlık bir Linux makinesi kullanın. Üretim verisi içermemeli ve üretim uygulamaları, giden posta veya zamanlanmış işlerle bağlantısı olmamalıdır. Yalnızca bu tatbikatta oluşturulan arşivi kullanın.

Komutlar, adı verilen önceden yapılandırılmış, süper kullanıcı olmayan bir veritabanı rolünü varsayar restore_lab, test veritabanları oluşturma izni ve yerel olarak kimlik doğrulayabilen aynı ada sahip bir işletim sistemi oturumu. PostgreSQL soketi /var/run/postgresql 5432 bağlantı noktasındadır. Yöneticiden bu hesabı tek kullanımlık ortamda hazırlamasını isteyin; bu kılavuz veritabanı erişim kurallarını değiştirmez. Herhangi bir şey oluşturmadan önce uç noktayı kontrol edin:

psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version

Ana bilgisayar, hesap veya sürüm beklenmedikse durun. Bu ilk tatbikat için istemcileri ve sunucuyu aynı ana sürümde tutun. pg_dump kendi ana sürümünden daha yeni bir sunucuyu dökümleyemez ve daha eski bir geri yükleme hedefi genellikle uyumlu olduğu garanti edilmez. Bakınız pg_dump sürüm sınırları. Her bloğu ayrı ayrı çalıştırın ve bir hatada durun. && korumaları, yapıştırılan bir bloktaki sonraki komutların bir hatadan sonra çalışmasını engeller; başarısız bir veritabanı veya dizin oluşturmadan sonra asla bir sonraki bloğa geçmeyin.

Bir kayıt ve eşleşen dosyasını oluşturun

Adlar offvps_restore_source ve offvps_restore_target kullanılmamış olmalıdır. Mevcut bir veritabanı, bırakmak için değil, durup yeni bir izole tatbikat seçmek için bir nedendir. Yeni bir dosya sistemi çalışma alanı ve kaynak veritabanı oluşturun:

umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_source

Yeni çalışma alanı, mevcut bir dizinin üzerine yazmayı önler. mktemp benzersiz bir dizin oluşturur; createdb seçilen şablondan yeni bir veritabanı oluşturur. Şu iki işaretçiyi kaydedin:

psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
  -U restore_lab -d offvps_restore_source \
  -c "CREATE TABLE notes (
        id integer PRIMARY KEY,
        body text NOT NULL,
        attachment text NOT NULL
      );
      INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"

Kayıt, notun hangi dosyaya ait olduğunu söyler ve her ikisi de aynı işaretçiyi içerir. Bu, eksik bir ek veya uyuşmayan bir kopyayı görünür kılar. -X kişisel psql başlangıç ayarlarından kaçınır ve ON_ERROR_STOP bir SQL hatasında durur; bakınız psql betikleme seçenekleri. Bu oyuncak veri kümesine yazan bir uygulama yoktur.

Veritabanını ve dosyaları tek bir kurtarma seti olarak yakalayın

pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
  --format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"

Özel biçimli arşiv şu şekilde okunur: pg_restore; düz bir SQL dökümü farklı bir geri yükleme prosedürünü izler. Arşivi listelemek, beklenen tablo ve veri girdilerinin mevcut olduğunu doğrulamaya yardımcı olur. Tutarlı bir veritabanı dökümü, harici yüklemeleri otomatik olarak eşitlemez. Gerçek bir uygulama için, dosya ağacı ve veritabanının aynı zaman noktasını tanımlaması amacıyla belgelenmiş bakım veya yazma duraklatma prosedürünü kullanın. Oyuncak tatbikat zaten sessizdir.

Veritabanı sürümünü, uygulama sürümünü, yakalama başlangıç/bitişini ve dosya yolunu paketin yanına kaydedin. Gerçek kimlik bilgilerini uygun erişim kontrolleri altında ayrı tutun. Veritabanı başına döküm, genel rolleri ve tablo alanlarını yakalamaz; gerçek bir kurtarma planı bunları da hesaba katmalıdır. Kapsam şurada açıklanmıştır: PostgreSQL’in SQL döküm kılavuzu.

Mevcut bir hedefi temizlemeden yeni hedeflere geri yükleyin

createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
  --dbname=offvps_restore_target --no-owner --no-acl \
  --single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"

Hedef veritabanı boş olarak oluşturulur. Geri yükleme kasıtlı olarak şunu atlar: --clean, bu mevcut nesneleri kaldırabilir. --single-transaction bu küçük veritabanı geri yüklemesini bir birim olarak başarılı kılar veya kısmi değişikliklerini uygulamadan durur; paralel işlerle birleştirilemez. --no-owner ve --no-acl bu test rolü için sahipliği basitleştirir, dolayısıyla bu tatbikat uygulamanın üretim rollerini veya izinlerini doğrulamaz. Bakınız pg_restore.

Dosya kopyası, kaynağı sağlam bırakarak yeni geri yükleme dizinini hedefler. GNU cp -a dosya özniteliklerini korumaya çalışır; gerçek bir uygulamayı çalıştıracak hesap için sahipliği ve erişimi inceleyin. Bayt kopyalamak, uygulama izinlerinin testi değildir. Bakınız cp’nin arşiv seçeneği.

Yalnızca çıkış kodlarını değil, ilişkiyi kontrol edin

psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
  -d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"

Beklenen sonuçlar, ID 1, gövde içeren bir satır restore-marker-01 ve ek marker.txt, artı şunu içeren bir dosyadır: restore-marker-01. Kaynağın hala orijinal satırını ve dosyasını içerdiğini kontrol edin. Gerçek uygulamanız için ayrıca izole bir örneği geri yüklenen veritabanına ve yükleme dizinine yönlendirin, temsili kayıtları açın, bir ek alın ve amaçlanan oturum açma izinlerini test edin. Bunu yaparken geri çağırmaları, postayı ve işleri sınırlı tutun.

Kanıtladığınızı ve kalanları yazın

Yukarıdaki beklenen çıktılar, OffVPS tarafından zaten gözlemlenmiş sonuçlar değil, tatbikat kriterleridir. İlk tatbikat tüm dosyaları tek bir makinede tuttuğu için o makinenin kaybına karşı koruma sağlamaz. Gerçek bir plan, ayrı bir hata etki alanında korumalı bir kopya, kullanılabilir şifre çözme anahtarları, saklama ve test edilmiş bir alma yolu gerektirir. Daha sonraki temizlikten önce tam tek kullanımlık veritabanı adlarını ve dizini gözden geçirin; üretimi bu sürecin dışında tutun.

Önemli değişikliklerden sonra tatbikatı tekrarlayın ve başarısızlıkları başarılar kadar dikkatle kaydedin. İsteğe bağlı bir yedekleme hizmeti, uygulamanızın kurtarma süresini kanıtlamaz. Şununla devam edin: zamanlanmış bir görevi planlama yakalamayı otomatikleştirmeye hazır olduğunuzda, ayrı bir geri yükleme tatbikatını koruyarak.