Ubuntu VPS yedekleme ve dosya kurtarma denemesi
Ubuntu VPS yedekleme işlemini, kopyayı sunucu dışında alıp beklenen dosyaları geri yükleyerek sınayın. Bu deneme bir statik sayfa ve bir Nginx yapılandırma dosyasını arşivler. Çalışan siteyi değiştirmeden aktarılan ve açılan dosyaların sağlama toplamlarını karşılaştırır.
İçindekiler
Denemenin kapsamını belirleyin
Bash, GNU tar, sha256sum ve OpenSSH kullanılır. Sunucu komutları tek sunucu terminalinde, istemci komutları ayrı bilgisayardaki Ubuntu/Linux/WSL terminalinde çalışmalıdır. Değişkenler sonraki adımlarda kullanılacağından terminalleri açık tutun. Herhangi bir komut hatasında durun.
Önce ev dizininizde iki geçici dosyayla çalışın. Nginx, firewall ve canlı içerik değişmez; arşiv root olarak açılmaz. İsteğe bağlı gerçek dosyalar yalnızca statik HTTPS rehberinin iki dosyasıdır.
Büyük bir site için diğer içerik, yönlendirme, dahil edilen yapılandırma, DNS ve bağımlılıkları ayrıca envantere alın. İki dosya bütün makine veya uygulama yedeği değildir.
Canlı siteyi değiştirmeden iki dosya hazırlayın
Sunucuda özel deneme klasörü oluşturun. Aşağıdaki Nginx metni arşivlenecek dosyadır; etkinleştirilecek servis yapılandırması değildir.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="tr"><title>Geri yükleme denemesi</title><h1>Kurtarılan statik sayfa</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Deneme klasörü: %s\n' "$backup_lab"İsteğe bağlı olarak rehberdeki gerçek sayfa ve server block dosyasını kullanmak için yalnızca geçici kopyaları aşağıdaki komutlarla değiştirin. İki kaynak da hesabınızca okunabilir olmalıdır. Yapılandırmayı sırlar açısından inceleyin ve dosyalar aynı sürümü temsil etsin diye toplama sırasında yayın yapmayın. Geçici örnekle çalışıyorsanız bu bloğu atlayın.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"Komutlar canlı kaynağı yalnızca okur. Sertifika özel anahtarlarını veya tüm sistem dizinlerini kopyalamaz. Gereken ek dosyaları hem envantere hem sağlama toplamı listesine bilinçli olarak ekleyin.
Arşivi ve iki seviyeli sağlama toplamını oluşturun
Sunucuda seçilen dosyaların toplamını kaydedin, göreli yollarla arşiv oluşturun ve arşivin toplamını alın. Bu adım sırasında içeriği değiştirmeyin.
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Sunucudaki dışa aktarma klasörü: %s\n' "$backup_lab/export"Listede site/, nginx/, iki seçilen dosya ve SHA256SUMS bulunmalıdır. Arşiv toplamı aktarımda değişikliği, iç liste açılan dosyaları sınar. Bir kişi veriyle beklenen toplamı birlikte değiştirebiliyorsa bu kontroller kaynağın gerçekliğini doğrulamaz.
Kopyayı başka bilgisayara alın
İstemci bilgisayarında remote_backup değerini sunucunun yazdırdığı tam dışa aktarma diziniyle değiştirin. Hesap, IP ve anahtar için çalışan SSH bilgilerinizi kullanın. 203.0.113.10 örnek adrestir; REPLACE, mktemp tarafından üretilen gerçek son ek değildir.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"Yeni sunucu anahtarını güvenilir kanaldan doğrulayın. SCP, SSH nedeniyle başarısızsa bağlantı teşhisini izleyin; kontrolü kapatmayın.
SCP aktarımı SSH ile korur. tar.gz dosyası sıkıştırılmıştır, şifrelenmiş değildir. Hedef hesabı ve depoyu koruyun; veri gerektiriyorsa diskte şifreleme kullanın. Aynı VPS üzerindeki ikinci klasör sunucu dışı yedek sayılmaz.
Boş bir klasöre açıp içeriği doğrulayın
İstemcide arşivi açmadan önce toplamını kontrol edin. Yalnızca sha256sum OK bildirirse devam edin. Hata varsa nedeni inceleyin veya yeniden aktarın; beklenen toplamı hatayı saklamak için değiştirmeyin.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Güvendiğiniz bu arşivi yeni oluşturulan dizine açın. keep-old-files mevcut dosyaları değiştirmeyi reddeder; no-same-owner arşivdeki sahipliğin geri yazılmasını önler. Hedefi / yapmayın, sudo ile açmayın.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"site/index.html ve nginx/first-site.conf için OK ve kurtarılan sayfa başlığını bekleyin. Bu, dosya içeriğini doğrular; üretim izinlerini, ACL, servis erişimini veya sitenin tüm bağımlılıklarını değil.
Dosya kurtarmayı hizmet kurtarmadan ayırın
Kurtarılan Nginx dosyası hâlâ etkin olmayan metindir. Ayrı yedek sunucuda yolları, includes, modülleri, izinleri ve sertifikaları kontrol edin. Birleştirilmiş yapılandırmayı o makinede doğrulayıp yeniden yükleyin, ardından dışarıdan HTTP/HTTPS test edin. Değişmemiş canlı sunucuda syntax testi bu kopyayı sınamaz.
Arşiv TLS özel anahtarlarını içermez. Yeniden sertifika üretimi veya ayrıca korunan sertifika yedeği planlayın. Etkin veritabanı dosyalarını bu tar tarifiyle kopyalamayın; veritabanının desteklediği tutarlı yedek ve geri yükleme yöntemini kullanın.
Sağlayıcı snapshot’ları makine kurtarmaya yardımcı olabilir. Saklama süresi, aynı arızadan etkilenme riski ve geri yükleme sürecini kontrol edin. Snapshot’ın varlığı dışarı aktarılan dosyaların başka makinede çalışacağını göstermez.
Hedefleri ve gerçek sonucu kaydedin
RPO zaman olarak kabul edilebilir veri kaybını, RTO hizmeti geri getirmek için hedef süreyi belirtir. Küçük statik bilgi sitesi için 24 saat RPO ve 60 dakika RTO örnek hedef olabilir; bu denemede ölçülmüş sonuç değildir. Günlük yedek ancak başarılı ve geri yüklenebilir kopyalar varsa anlamlıdır.
Diğer sütunlar için tabloyu yana kaydırın →
| Kayıt | Gösterdiği bilgi |
|---|---|
| Yedek zamanı ve sürüm kimliği | Hangi sürüm kurtarılabilir |
| Bağımsız hedef ve saklama süresi | Kopya nerede ve ne kadar süre kalır |
| Arşiv ve dosya toplamları | Seçilen baytlar doğrulandı mı |
| Kurtarma başlangıcı ve bitişi | Tanımlı adımların gerçek süresi |
| Eksik dosya, izin veya bağımlılık | Hizmeti açmadan kalan işler |
| Yeni ortamda dış HTTPS kontrolü | Site gerçekten geri döndü mü |
RTO’ya güvenmeden erişim, makine oluşturma, yapılandırma, sertifika ve gerekiyorsa DNS dahil tüm süreci ölçün. Hızlı yerel arşiv açma bir kesinti kurtarma benchmark’ı değildir. Uygun geçmiş kopyaları saklayın, başarısız yedek işleri için uyarı alın ve hosting kurtarma koşullarını bütçeyle değerlendirin.
Sorular ve yanıtlar
Yedeği sınamak için asıl siteyi silmeli miyim?
Hayır. Ayrı boş klasöre açıp toplamları denetlemek dosya kopyasını kesinti yaratmadan sınar. Tam hizmeti ayrı bir yedek ortamda deneyin.
Sağlama toplamı başarılıysa her şey yedeklenmiş mi?
Yalnızca listedeki dosyalar doğrulanır. Eksik varlık, veritabanı, sır veya DNS kaydı kendiliğinden bulunmaz. Envanter tutup uygulamanın işlevlerini ayrıca test edin.
SCP ile alınan arşiv şifreli midir?
SSH aktarımı korur, tar.gz arşivinin kendisi şifreleme sağlamaz. Depolama ve erişim korumasını ayrıca planlayın.