VPS Yedekleme ve Snapshot: Farkları, Araçlar ve Otomasyon

Bir VPS’teki veriyi korumanın birbirinin yerine geçmeyen iki aracı vardır: snapshot, diskin o anki hâlini dakikalar içinde geri getirir; yedek ise veriyi sunucudan bağımsız bir yerde, haftalar ve aylar geriye uzanan sürümlerle saklar. VPS yedekleme düzenini ikisini birlikte planlayarak kurmak, hem başarısız bir güncellemeye hem de diskin, hesabın ya da verinin tamamen kaybına karşı korur.

Yönetilmeyen bir VPS sunucuda yedeğin sorumluluğu çoğunlukla sizdedir; sağlayıcının sunduğu yedek ve snapshot seçenekleri pakete göre değişir, LIONFIN VPS paketlerindeki güncel özellikleri paket sayfasından kontrol edin. Örneklerdeki komutlar root yetkisiyle çalıştırılmak üzere yazıldı; Ubuntu 24.04 LTS ve güncel Debian sürümlerinde paket adları aynıdır.

Snapshot ile yedek arasındaki fark nedir?

Snapshot, sanal diskin belirli bir andaki görüntüsüdür ve genellikle aynı depolama altyapısında tutulur; yedek ise verinin sunucudan ayrı bir yere alınmış, geçmiş sürümleriyle saklanan kopyasıdır.

Kısacası snapshot “az önceki hâle dön” düğmesi, yedek ise felaket sigortasıdır. Fiziksel sunucularda kullanılan RAID de yedeğin yerini tutmaz; disk arızasına dayanır ama silinen dosyayı geri getirmez, ayrıntı RAID nedir yazısında.

VPS’te neler yedeklenmeli?

Bir VPS’i yeniden kurabilmek için verinin yanında yapılandırmayı da yedeklemeniz gerekir; yalnızca site dosyalarını almak, sunucuyu baştan ayarlamak zorunda bırakır. Kapsam listesi:

• Veritabanları: Ham veri klasörü değil, döküm dosyaları (bir sonraki bölüm).
• Uygulama ve site dosyaları: /var/www, /home ve kullanıcı yüklemeleri.
• Yapılandırma: /etc klasörünün tamamı (Nginx, PHP-FPM, SSH ve güvenlik duvarı ayarları) ve /etc/letsencrypt altındaki sertifikalar.
• Zamanlanmış görevler: /etc/cron.d ve kullanıcı crontab’leri (/var/spool/cron/crontabs).
• Paket listesi: apt-mark showmanual > /root/paketler.txt çıktısı, yeni sunucuda aynı yazılımları kurmayı kolaylaştırır.

Hariç tutulacaklar: /proc, /sys, /dev, /run, /tmp, önbellek klasörleri ve çalışan veritabanının ham dosyaları. Kopyaların nerede ve kaç tane tutulacağını 3-2-1 yedekleme kuralı belirler: en az bir kopya hem sunucunun hem de sağlayıcının dışında olmalıdır.

Veritabanı tutarlı biçimde nasıl yedeklenir?

Veritabanı, kendi döküm aracıyla yedeklenir; çalışan bir veritabanının dosyalarını kopyalamak yarım yazılmış sayfalar içeren, açılmayabilen bir kopya üretir. MySQL ve MariaDB’de --single-transaction seçeneği InnoDB tablolarını kilitlemeden tek bir tutarlı anın görüntüsünü alır:

mkdir -p /var/backups/db
mysqldump --single-transaction --quick --routines --triggers --events \
  site_db | gzip > /var/backups/db/site_db-$(date +%F).sql.gz

MariaDB’nin yeni sürümlerinde aynı araç mariadb-dump adıyla gelir ve aynı seçenekleri kabul eder. Debian ve Ubuntu’da root kullanıcısı veritabanına genellikle soket kimlik doğrulamasıyla bağlandığı için parola gerekmez; gerekiyorsa kimlik bilgilerini 600 izinli /root/.my.cnf dosyasına yazın, komut satırına parola koymayın. MyISAM tablolarında --single-transaction tutarlılık sağlamaz; bu tabloları InnoDB’ye dönüştürmek en temiz çözümdür.

PostgreSQL’de sıkıştırılmış özel biçim (-Fc) tercih edilir; geri yükleme pg_restore ile yapılır:

sudo -u postgres pg_dump -Fc site_db > /var/backups/db/site_db-$(date +%F).dump

Dosyalar rsync ile başka sunucuya nasıl kopyalanır?

rsync, yalnızca değişen dosyaları SSH üzerinden aktardığı için düzenli dosya kopyası almanın en hafif yoludur. Yedek sunucusuna parolasız giriş için önce bir anahtar tanımlayın (SSH anahtarı oluşturma), ardından:

rsync -aH --delete \
  -e "ssh -i /root/.ssh/yedek_anahtari" \
  /etc /var/www /home /var/backups/db \
  yedek@YEDEK_SUNUCU:/yedekler/vps1/

-a izinleri ve zaman damgalarını, -H sabit bağlantıları korur; dosya sahipliğinin korunması ise hedef tarafta root yetkisi ister. Bu komut bir ayna üretir: kaynakta silinen ya da fidye yazılımıyla şifrelenen dosya, bir sonraki çalıştırmada hedefte de silinir veya bozulur. Bu yüzden rsync tek başına sürüm geçmişi sunmaz; hedef tarafta günlük kopyalar tutmanız ya da bir sonraki bölümdeki araçlardan birini kullanmanız gerekir.

Bir güvenlik ayrıntısı daha: VPS ele geçirilirse saldırgan, sunucudaki anahtarla yedeklere de ulaşabilir. Mümkünse yedek sunucusunun veriyi VPS’ten kendisinin çekmesini (pull) sağlayın ya da yedek hesabını yalnızca ekleme yapabilecek biçimde kısıtlayın.

restic ile şifreli ve tekilleştirilmiş VPS yedekleme

restic ve BorgBackup, her çalıştırmada yalnızca değişen veri bloklarını saklayan (tekilleştirme), yedeği daha sunucudan çıkmadan şifreleyen ve her çalıştırmayı ayrı bir anlık görüntü olarak tutan araçlardır. Böylece rsync aynasının eksik bıraktığı sürüm geçmişini sağlarlar; dosya sahipliği ve izinler de deponun içinde saklanır. restic’in avantajı, hedef olarak düz bir SFTP hesabını ya da S3 uyumlu nesne depolamayı kabul etmesidir:

apt install restic
export RESTIC_REPOSITORY=sftp:yedek@YEDEK_SUNUCU:/yedekler/vps1
export RESTIC_PASSWORD_FILE=/root/.restic-parola

restic init          # yalnızca ilk seferde
restic backup /etc /var/www /home /var/backups/db --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

Parola dosyasını 600 izinle oluşturun ve bir kopyasını sunucu dışında, bir parola yöneticisinde saklayın: restic depoyu her zaman şifreler, parola kaybolursa yedekler açılamaz. BorgBackup benzer biçimde çalışır (borg init, borg create, borg prune), ancak uzak tarafta da borg kurulu olmasını ister; 1.2 ve sonraki sürümlerde borg prune ardından alanı geri kazanmak için borg compact çalıştırılır.

Zamanlama ve saklama: cron ile otomasyon

Yedek ancak insan müdahalesi olmadan her gün çalışıyorsa güvenilirdir; döküm ve yedek adımlarını tek betikte toplayıp /etc/cron.d altından zamanlayın. Örnek /usr/local/sbin/vps-yedek betiği:

#!/bin/bash
set -euo pipefail
export RESTIC_REPOSITORY=sftp:yedek@YEDEK_SUNUCU:/yedekler/vps1
export RESTIC_PASSWORD_FILE=/root/.restic-parola

mysqldump --single-transaction --quick --routines --triggers --events \
  site_db > /var/backups/db/site_db.sql
restic backup /etc /var/www /home /var/backups/db --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Dökümü burada sıkıştırmadan yazmak bilinçli bir tercihtir: gzip çıktısı küçük bir değişiklikte bile o noktadan sonra tamamen farklılaştığı için tekilleştirmeyi bozar, sıkıştırmayı ise restic kendisi yapar (0.14 ve sonraki sürümlerin depo biçiminde). Betiği chmod 700 ile çalıştırılabilir yapın ve /etc/cron.d/vps-yedek dosyasına, kullanıcı alanını da içeren şu satırı yazın:

30 3 * * * root /usr/local/sbin/vps-yedek >> /var/log/vps-yedek.log 2>&1

Saklama değerleri örnektir; yedi günlük, dört haftalık ve altı aylık sürüm çoğu sitede geç fark edilen hatalara yetecek geçmişi makul depo boyutuyla dengeler. set -euo pipefail satırı, döküm başarısız olursa betiğin sessizce devam etmesini engeller. Bu VPS yedekleme betiğinin günlüğünü izleme aracınıza bağlayıp başarısız geceler için uyarı kurun.

Geri yükleme provası nasıl yapılır?

Bir yedeğin çalıştığını yalnızca ondan geri dönerek kanıtlayabilirsiniz; üç ayda bir, ayrı bir test sunucusunda şu provayı yapın:

1. Anlık görüntüleri listeleyin: restic snapshots.
2. Son yedeği geçici bir klasöre açın: restic restore latest --target /tmp/prova.
3. Boş bir test veritabanı oluşturup dökümü yükleyin: mysql test_db < /tmp/prova/var/backups/db/site_db.sql; PostgreSQL için pg_restore -d test_db dosya.dump.
4. Uygulamayı test sunucusunda çalıştırıp son siparişin, son yazının ya da son kaydın yerinde olduğunu kontrol edin.
5. Başlangıçtan çalışır duruma kadar geçen süreyi not edin; bu sizin gerçek geri dönüş sürenizdir (RTO, Recovery Time Objective).

Prova sırasında eksik çıkan her şey (unutulmuş bir yapılandırma dosyası, kayıp parola, beklenenden uzun süren indirme) gerçek bir felakette çok daha pahalıya patlar. Test sunucusunu kurarken VPS ilk kurulum adımları rehberindeki temel güvenlik ayarlarını uygulayın; yalnızca prova için açılan bir sunucu bile canlı veri taşır.

Riskli işlemlerden önce snapshot ne zaman alınmalı?

Snapshot en çok, geri dönüşü zor bir değişikliğin hemen öncesinde değerlidir: dağıtım sürümü yükseltmesi (Ubuntu’da do-release-upgrade), çekirdek, PHP ya da veritabanında ana sürüm güncellemesi, güvenlik duvarı ve SSH ayarlarında büyük değişiklik, kontrol paneli kurulumu. Sağlayıcınızın panelinde snapshot özelliği varsa şu sırayı izleyin:

1. Uygulamayı bakım moduna alın ya da trafiğin en düşük olduğu saati seçin.
2. Veritabanının güncel bir dökümünü alın; snapshot çökme tutarlı olduğundan döküm ek güvencedir.
3. Snapshot’ı alın, işlemi yapın ve sonucu doğrulayın.
4. Her şey yolundaysa snapshot’ı birkaç gün içinde silin.

Uzun süre tutulan snapshot’lar depolama alanı tüketir ve bazı platformlarda disk performansını düşürebilir; onları kalıcı arşiv olarak değil, geri alma ağı olarak kullanın. Yedek saatinde disk yükünün nasıl etkilendiğini görmek için Linux sunucu performans izleme komutlarından yararlanabilirsiniz.