VPS Yedeği ve Geri Yükleme: Uygulanabilir Plan

1. Kaybetmeyi göze aldığınız zamanı belirleyin

RPO, veri kaybına ilişkin hedefinizdir: bir olaydan sonra en fazla kaç saatlik değişikliği kaybetmeyi kabul ediyorsunuz? RTO ise hizmeti geri getirme süresi hedefidir. Bunlar satın alınan bir garanti değil, teknik planı ve provayı yönlendiren iş kararlarıdır. Örneğin günde bir yedek, son başarılı yedekten sonraki yaklaşık bir günlük değişikliği riske bırakabilir; yedek başarısızlıkları bu aralığı büyütür.

Sık yedek almak kadar geri getirme süresi de önemlidir. Yeni VPS kurma, veriyi indirme, sırları geri verme, DNS değiştirme ve doğrulama adımları toplam süreye dahildir. Hedefiniz kısa ise bu adımları otomatikleştirmek veya hazır bir ikinci ortam tutmak gerekebilir.

2. Dosya ve veritabanı kapsamını çıkarın

• Uygulama verisi: yüklenen dosyalar, kalıcı volume’lar, kullanıcı içerikleri.
• Veritabanı: tutarlı dump veya ürünün desteklediği fiziksel yedek.
• Yapılandırma: Nginx, systemd, Compose ve gerekli DNS kayıtları.
• Sırlar: .env, veritabanı bilgileri ve uygulama şifreleme anahtarı.
• Geri dönüş bilgisi: uygulama sürümü, image digest’i ve kurulum sırası.

Yedek deposunun parolasını yalnızca yedeğin içinde saklamayın. Sunucu kaybolduğunda parolaya erişemiyorsanız şifreli veri de kullanılamaz. Parolayı kurumun erişim politikasına uygun bir parola yöneticisinde veya ayrı güvenli kayıtta tutun. Uygulama sırları içeren yedeklere erişimi de üretim verisi gibi sınırlandırın.

3. Restic deposunu hazırlayın

Örnek SFTP hedefi size ait ayrı bir yedek sunucusudur. backup.example gerçek bir hedef değildir; kendi alan adınız, kullanıcınız ve yazılabilir depo yolunuzla değiştirin. SFTP bağlantısını ve sunucu anahtarını önceden doğrulayın. Yedek sunucusunda bu iş için sınırlı bir hesap kullanın.

sudo apt update
sudo apt install restic nano
sudo -i

Aşağıdaki komutlar açtığınız root kabuğunda çalışır. Parola dosyasını oluşturmak için nano kullanın; parolayı komut satırına veya kabuk geçmişine yazmayın. Dosyaya güçlü, benzersiz depo parolanızı tek satır olarak kaydedin.

umask 077
touch /root/restic-password
chmod 600 /root/restic-password
nano /root/restic-password
export RESTIC_PASSWORD_FILE=/root/restic-password
export RESTIC_REPOSITORY="sftp:backupuser@backup.example:/srv/restic/serverq"
restic init
restic snapshots

init yalnızca yeni bir depo oluşturmak içindir; zaten hazırlanmış bir depoda snapshots ile bağlantıyı kontrol edin. SFTP anahtarı root hesabından okunabilir olmalıdır. Anahtarı veya hedef host bilgisini doğrulamadan SSH host kontrolünü devre dışı bırakmayın. Ortam değişkenleri yalnızca bu kabukta kalır; zamanlanmış görev için aynı bilgileri güvenli bir yapılandırmayla sağlamanız gerekir.

4. Tutarlı bir yedek alın

Aşağıdaki örnek WordPress adlı bir MariaDB veritabanını dump eder. --single-transaction, InnoDB gibi işlemsel tablolar için tutarlılık sağlar; işlemsel olmayan tablolar ve eş zamanlı şema değişiklikleri için ek plan gerekir. Dump sırasında eklenti güncellemesi veya tablo değişikliği yapmayın. Dosyalarla veritabanının birebir aynı anda kalması gerekiyorsa bakım modu veya uygulamaya uygun tutarlı snapshot yöntemi kullanın.

install -d -m 0700 /root/backup-staging
if mariadb-dump --single-transaction --routines --events wordpress > /root/backup-staging/wordpress.sql.tmp; then
  mv /root/backup-staging/wordpress.sql.tmp /root/backup-staging/wordpress.sql
else
  echo "Veritabani yedegi basarisiz; yedekleme durduruldu." >&2
  exit 1
fi
restic backup /var/www/wordpress /etc/nginx /root/backup-staging
restic snapshots
restic check

restic check depo yapısını kontrol eder. Tüm veri paketlerini okuyarak denetim için restic check --read-data kullanılabilir; büyük depoda süre ve çıkış trafiği maliyeti oluşturur. Günlük bir görevin sadece zamanlanmış olması başarı kanıtı değildir: çıkış kodu, son başarılı snapshot zamanı ve beklenen veri miktarı izlenmelidir.

5. Üretime dokunmadan geri yükleme provası yapın

RESTORE_DIR=$(mktemp -d /var/tmp/serverq-restore.XXXXXX)
restic restore latest --target "$RESTORE_DIR"
find "$RESTORE_DIR" -maxdepth 3 -type d
restic check --read-data

Önce hangi snapshot’ın doğru olduğunu snapshots ile seçin. latest en yeni başarılı kopyadır; hatalı verinin de yedeklenmiş olabileceğini unutmayın. Gerçek olayda ihtiyaç duyduğunuz snapshot kimliğini kullanın. Geri yüklenen klasörü üretimdeki dizinin üzerine otomatik olarak kopyalamayın.

1. Dosya sayısını ve beklediğiniz kritik dosyaların içeriğini inceleyin.
2. Veritabanını ayrı bir test veritabanına aktarın; üretim veritabanının üzerine yazmayın.
3. Uygulamayı doğru sürüm ve aynı şifreleme anahtarıyla izole ortamda açın.
4. E-posta, ödeme, webhook ve zamanlanmış işleri dış etki yaratmayacak şekilde devre dışı bırakın.
5. Oturum açma, bir veri okuma/yazma işlemi ve örnek medya dosyasını doğrulayın.
6. Başlama ve bitiş zamanını kaydedip gerçek RTO’yu hedefinizle karşılaştırın.

n8n gibi sırları şifreleyen bir uygulamada veritabanı geri gelmiş olsa da doğru anahtar olmadan kimlik bilgileri çözülemeyebilir. WordPress’te medya dosyaları eksikse sayfalar açılırken görseller kaybolabilir. Provanın amacı yalnızca servis durumunu değil kullanıcı açısından temel işlevi doğrulamaktır.

6. Saklama ve erişim politikasını uygulayın

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run

Bu sadece bir örnek saklama dağılımıdır. Hukuki, operasyonel ve maliyet gereksinimlerinize göre belirleyin. --dry-run hangi snapshot’ların unutulacağını gösterir; otomatik silme politikasına geçmeden önce çıktıyı ve bağımsız ikinci kopyayı kontrol edin. Depodaki fiziksel alanı geri kazanma işlemi ayrıca prune gerektirir ve veri siler.

Bir saldırgan üretim sunucusuna erişirse aynı sunucuda bulunan yedek erişim bilgilerini de kullanabilir. Mümkünse silmeye karşı ayrı koruma, nesne kilidi veya bağımsız kopya tasarlayın. Yetkili kişileri ve yedek parolasına acil erişim sürecini belgeleyin. Son olarak, her önemli uygulama veya veritabanı değişikliğinden sonra geri yükleme provasını tekrarlayın.