VPS yedekleri: stratejiler ve araçlar

Yedek genellikle ihtiyaç duyulduğu anda akla gelir: bir güncelleme veritabanını bozmuştur, biri site klasörünü silmiştir, sağlayıcıda disk arızalanmıştır ya da sunucu ele geçirilmiştir. Bu durumların her birinde sizi herhangi bir yedek değil, başka bir yerde duran, yakın zamanda alınmış ve en az bir kez geri yükleme yaptığınız yedek kurtarır. Aşağıda böyle bir yedeğin sıradan bir Linux sunucusunda nasıl kurulacağı anlatılıyor.

Sağlayıcıdaki anlık görüntü henüz bir strateji değildir

Birçok sağlayıcı panelde disk anlık görüntüleri (snapshot) ve otomatik yedekler sunar. Bu faydalıdır, ancak böyle bir yedeğin üç zayıf noktası vardır.

• Aynı sağlayıcıda durur. Bir ödeme hatası, hesabın kapatılması, veri merkezinde bir arıza veya çalınmış bir panel parolası, sunucuyu ve tüm anlık görüntülerini aynı anda götürür.
• Yedekler az ve seyrektir. Çoğu zaman günde veya haftada bir alınan son bir iki yedektir. Arıza birkaç gün sonra fark edilirse sağlam bir sürüm kalmamış olabilir.
• Anlık görüntüdeki veritabanı her zaman sağlam değildir. Anlık görüntü diski rastgele bir anda, sanki sunucu aniden kapatılmış gibi kaydeder. InnoDB ve PostgreSQL bundan sonra genellikle toparlanır, ancak garantisi yoktur; MyISAM tabloları ise bozulmuş olabilir.

Anlık görüntü, bir güncellemeden önce hızlı bir geri dönüş noktası olarak kullanışlıdır. Asıl yedekleri kendi araçlarınızla alıp ayrı bir yerde saklamak gerekir.

3-2-1 kuralı

Klasik şema şöyledir: verilerin üç kopyası, iki farklı ortamda veya sistemde, bunlardan biri başka bir yerde. VPS için bu genellikle şöyle görünür:

1. Sunucunun kendisindeki çalışan veriler.
2. Başka bir sunucuda veya başka bir sağlayıcıdaki, en azından başka bir veri merkezindeki S3 nesne depolamasında bir kopya.
3. Bir kopya daha: sağlayıcı panelindeki anlık görüntüler, ikinci bir yedekleme sunucusu veya evdeki bir depolama cihazına aktarım.

Buna bir kural eklemekte fayda var: en az bir kopya, çalışan sunucunun kendisinden silinememelidir. Saldırgan root yetkisi elde ettiyse yedek deposunun parolalarını da görür. Bunun nasıl kurulacağı aşağıda silinmeye karşı koruma bölümünde anlatılıyor.

Neler yedeklenmeli

Sistemin tamamını yedeklemek genellikle gerekmez: temiz bir sunucu şablondan dakikalar içinde kurulur. Değerli olan veriler ve ayarlardır.

Önbellekleri, geçici dosyaları, logları ve node_modules klasörünü hariç tutun: yedeği şişirirler ve kendiliğinden yeniden oluşurlar.

Veritabanları: yalnızca döküm

Çalışan bir sunucunun veritabanı dosyalarını kopyalamak olmaz: kopyalama sırasında değişirler ve tutarsız bir kopya elde edersiniz. Doğru yol dökümdür. MySQL ve MariaDB için:

mysqldump --single-transaction --routines --triggers shop | gzip > /var/backups/shop-$(date +%F).sql.gz

--single-transaction bayrağı, yazmayı durdurmadan InnoDB tablolarının tutarlı bir dökümünü alır. MyISAM tablolarını bu bayrak korumaz: bu tür tablolar varsa onları InnoDB'ye dönüştürün veya dökümü --lock-all-tables ile alın. Debian ve Ubuntu'da root, MariaDB'ye soket üzerinden parolasız girer, bu yüzden komut root olarak olduğu gibi çalışır; başka bir kullanıcı için kullanıcı adı ve parolayı izinleri 600 olan ~/.my.cnf dosyasına koyun.

PostgreSQL için:

sudo -u postgres pg_dump -Fc shop > /var/backups/shop-$(date +%F).dump
sudo -u postgres pg_dumpall --globals-only > /var/backups/pg-globals.sql

İkinci dosya, tek bir veritabanının dökümünde bulunmayan rolleri ve yetkileri saklar. Böyle bir döküm pg_restore -d shop dosya.dump komutuyla geri yüklenir. Veritabanı onlarca gigabayt tutuyorsa ve döküm çok uzun sürüyorsa fiziksel yedeklemeye bakın: MySQL için mariabackup veya Percona XtraBackup, PostgreSQL için pgBackRest.

Dökümleri tek bir klasörde, örneğin /var/backups içinde toplayın ve bu klasörü dosya yedeğine dahil edin; böylece her şey tek bir komutla depoya gider.

Araçlar: rsync, restic, BorgBackup

rsync: yedek değil, ayna

rsync klasörleri hızla senkronize eder, ancak kendi başına bir yedek değildir: sunucuda silinen veya bozulan bir dosya, bir sonraki çalıştırmada aynada da silinir veya bozulur. Sürümleri --link-dest bayrağıyla elde edebilirsiniz: her çalıştırma yeni bir klasör oluşturur ve içindeki değişmemiş dosyalar bir öncekine sabit bağlantı olur, böylece yalnızca değişiklikler için yer harcanır. Bunu, verileri çalışan sunucudan kendisi çeken yedekleme sunucusunda çalıştırmak daha kullanışlıdır:

rsync -a --delete --link-dest=/backup/web/2026-10-30 root@web.example.com:/var/www/ /backup/web/2026-10-31/

Tek bir site için bu yeterlidir, ancak rsync şifreleme ve bütünlük kontrolü sağlamaz.

restic

restic bağımlılığı olmayan tek bir programdır. Verileri göndermeden önce şifreler, dosyaların yalnızca yeni parçalarını saklar ve SFTP'ye, S3 uyumlu bir depolamaya veya kendi rest-server'ına yazabilir. Depo bir kez oluşturulur, sonrasında yedek tek bir komutla alınır:

export RESTIC_REPOSITORY=sftp:backup@storage.example.com:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic init
restic backup /etc /var/www /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

forget komutu 7 günlük, 4 haftalık ve 6 aylık anlık görüntüyü tutar, --prune ise geri kalanların kapladığı yeri boşaltır. /root/.restic-pass içindeki parola olmadan depo hiçbir şekilde çözülemez, bu yüzden parolanın bir kopyasını sunucu dışında, örneğin bir parola yöneticisinde saklayın.

BorgBackup

Borg, restic'e benzer, ancak genellikle daha iyi sıkıştırır ve çok sayıda küçük dosyayla daha hızlı çalışır. Depoyu diskte veya SSH üzerinden başka bir sunucuda tutar ve orada da borg kurulu olmalıdır; S3'ü doğrudan desteklemez. 2026'da kararlı dal 1.4'tür, 2.0 sürümü hâlâ beta aşamasındadır ve gerçek yedekler için önerilmez. 1.4 için komutlar:

export BORG_REPO=ssh://backup@storage.example.com/./web1
export BORG_PASSCOMMAND="cat /root/.borg-pass"

borg init --encryption=repokey-blake2
borg create --stats --compression zstd ::'{hostname}-{now}' /etc /var/www /var/backups
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6
borg compact

1.2'den beri prune sonrasında yer yalnızca compact komutuyla boşaltılır. repokey modunda anahtar, deponun kendisinde parolayla korunarak saklanır; her ihtimale karşı onu borg key export komutuyla dışa aktarın ve sunucu dışında saklayın.

Sunucuda bir kontrol paneli varsa yerleşik yedeklerine bakın: ISPmanager, FASTPANEL ve aaPanel'de bunlar arayüzden ayarlanır ve arşivleri harici bir depolamaya gönderebilir. Panelli paket seçkileri: ISPmanager, FASTPANEL, aaPanel.

Yedekler nerede saklanmalı

• Başka bir sağlayıcıda ayrı bir VPS. Yedekler için hızlı bir işlemci değil, geniş bir disk gerekir. Bu tür paketler veri depolama için VPS, HDD VPS ve yedekler için VPS seçkilerinde toplandı.
• S3 nesne depolaması. Kullanılan gigabaytlar için ödeme yaparsınız, restic oraya doğrudan yazar. Depolama nesne sürümlemeyi veya belirli bir süre silme yasağını destekliyorsa bu aynı zamanda silinmeye karşı bir korumadır.
• Evdeki veya ofisteki bir depolama cihazı. Üçüncü kopya olarak iyidir: yedekleme sunucusu verileri SSH üzerinden kendisi çeker ve dışarıdan ona bağlanılamaz.

Veritabanında Rusya vatandaşlarının kişisel verileri varsa Rusya'nın 152-FZ sayılı kanununu hesaba katın: yedekleri de Rusya'daki sunucularda tutmak daha iyidir; seçki: 152-FZ için VPS.

Silinmeye karşı koruma

En kötü durum, bir saldırganın veya hatalı bir betiğin hem verileri hem yedekleri silmesidir. Bunu önlemenin üç yolu var.

• Göndermek yerine çekmek. Yedekleme sunucusu çalışan sunucuya kendisi bağlanır ve verileri çeker. Çalışan sunucunun yedeklere hiçbir erişimi yoktur.
• "Yalnızca ekleme" modu. borg için yedekleme sunucusundaki authorized_keys dosyasında çalışan sunucunun anahtarına bir komut atanır: command="borg serve --append-only --restrict-to-path /srv/borg/web1",restrict ssh-ed25519 AAAA…. Yeni arşivler eklenebilir, eskiler silinemez. restic için aynı işi --append-only bayrağıyla başlatılan rest-server yapar. Bu durumda eski yedeklerin temizliği güvenilir bir makineden başka bir anahtarla çalıştırılır.
• S3'te sürümleme ve silme yasağı. Depolama, nesnelerin önceki sürümlerini belirlenen süre boyunca kendisi saklar.

Zamanlama ve yedekleme sıklığı

Sıklık, ne kadar veri kaybetmeyi göze alabildiğinize bağlıdır. Bir blog için günde bir yedek yeterlidir. Gün boyu sipariş alan bir mağaza için veritabanı dökümünü saatte bir, dosyaları ise günde bir almak gerekir. Yedeği gece cron veya bir systemd zamanlayıcısıyla çalıştırın, örneğin 30 3 * * * root /usr/local/bin/backup.sh satırını içeren bir /etc/cron.d/backup dosyasıyla.

Sessizce alınmayı bırakan bir yedek, hiç yedek olmamasından daha kötüdür: korunduğunuzu sanırsınız. Betiğin sonunda harici izlemeye bir sinyal gönderin (kontrol adresine sıradan bir curl); sinyal zamanında gelmezse izleme hizmeti size yazar.

Geri yüklemeyi test edin

Ayda bir yedeği temiz bir sunucuya geri yükleyin ve sitenin açıldığını, verilerin yerinde olduğunu kontrol edin. Bunun için saatlik ücretlendirme kullanışlıdır: test sunucusu için yalnızca çalıştığı saatlerin ücretini ödersiniz.

restic restore latest --target /tmp/restore --include /var/www/site
restic check --read-data-subset=10%
borg extract ::web1-2026-10-31T03:30:00 var/www/site   # arşiv adı borg list çıktısından
borg check --verify-data

İkinci ve dördüncü komutlar depodaki yalnızca içindekiler dizinini değil, verilerin kendisini okur ve bozuk parçaları bulur. Geri yükleme adımlarını sunucu dışında ayrı bir dosyaya yazın: arıza anında komutları hatırlamaya vakit olmaz. Geri yükleme yapacağınız yeni sunucunun nasıl hazırlanacağı VPS satın aldıktan sonra ilk 10 adım: güvenlik yazısında, sitenin tamamen taşınması ise Bir site paylaşımlı hostingden VPS'e nasıl taşınır yazısında anlatılıyor.