Pratik Bir VPS Yedekleme Stratejisi (3-2-1 Kuralı)

ApexVPS ekibi tarafından yazıldı • Son güncelleme: Temmuz 2026 • 7 dk okuma

Güvenilir bir VPS yedekleme stratejisi, beş dakikalık bir kurtarma ile çok kötü bir hafta arasındaki farktır. Sunucular arızalanır, diskler bozulur, dağıtımlar ters gider ve tek bir yanlış yazılmış komut bir dizini silebilir. Cloudflare Learning Center ve çoğu altyapı ekibi aynı basit disipline işaret eder: 3-2-1 kuralı. Bu kılavuz, bunu gerçek bir sanal sunucuya nasıl uygulayacağınızı, hangi araçları kullanacağınızı ve her şeyi nasıl planlayıp test edeceğinizi gösterir; böylece bir geri yükleme ihtiyacınız olduğunda gerçekten çalışır.

3-2-1 Kuralının Anlamı

3-2-1 kuralı, sunucunuz nerede olursa olsun geçerliliğini koruyan onlarca yıllık bir yedekleme ilkesidir:

• 3 kopya veriniz — canlı kopya artı en az iki yedek.
• 2 farklı medya veya depolama sistemi — böylece tek bir arıza iki kopyayı birden yok edemez.
• 1 site dışı kopya — koruduğunuz makineden fiziksel veya mantıksal olarak ayrı.

Bir VPS'te bu genellikle çalışan sunucunuz, yerel bir yedek deposu ve farklı bir konumdaki uzak depolamaya gönderilen şifreli bir kopya anlamına gelir. Amaç, tek bir ortak arıza noktası olmadan yedekliliktir.

VPS'te Neler Yedeklenmeli

Tüm diski blok blok yedeklemek israf ve yavaştır. İyi bir yedekleme planı, yeniden oluşturulması gerçekten zor olan üç şeyi hedefler.

Uygulama verileri ve dosyalar

Yüklenen dosyalar, web sitesi kökleri, konteyner birimleri ve kullanıcıların oluşturduğu her şey. Tipik yollar şunları içerir: /var/www, /srv, /home ve Docker birim dizininiz. Dosya sunucusu veya wiki gibi uygulamaları kendi kendinize barındırıyorsanız, yeri doldurulamaz içeriğiniz burada yaşar — bu dizinlerin genellikle nasıl düzenlendiğini öğrenmek için kendi kendine barındırma için VPS çalıştırma rehberimize bakın.

Veritabanları

Hizmet çalışırken canlı veritabanı dosyalarını asla kopyalamayın — yarı yazılmış, bozuk bir durumu yakalayabilirsiniz. Bunun yerine tutarlı bir döküm dışa aktarın. MySQL veya MariaDB için:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

--single-transaction bayrağı, InnoDB tablolarını kilitlemeden tutarlı bir anlık görüntü sağlar. PostgreSQL için bunun yerine pg_dump kullanın:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

Sistem ve hizmet yapılandırması

Sunucunuzu size özel yapan dosyalar: /etc (nginx, systemd birimleri, cron, SSH yapılandırması), paket listeleri, TLS sertifikaları ve güvenlik duvarı kuralları. Bir arızadan sonra bunları bellekten yeniden oluşturmak, yedeklerin var olmasının amacı olan sıkıcı iştir.

Yedekleme Araçlarınızı Seçme

Üç araç neredeyse tüm VPS durumlarını kapsar. Tekilleştirme ve şifrelemeye ne kadar değer verdiğinize göre seçim yapın.

restic — şifreli, tekilleştirilmiş anlık görüntüler

restic varsayılan olarak şifreleyen ve tekilleştiren modern, tek dosyalık bir yedekleme aracıdır. Depoyu bir kez başlatın ve ardından ona karşı yedekleme çalıştırın:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — tekilleştiren arşivler

BorgBackup, biraz farklı bir iş akışıyla benzer tekilleştirme ve sıkıştırma sunar:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — basit dosya yansıtma

Yalnızca dosyaları başka bir ana bilgisayara hızlı bir şekilde yansıtmanız gerektiğinde, SSH üzerinden rsync zor yenilir:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

-aAX bayrakları izinleri, ACL'leri ve genişletilmiş öznitelikleri korur; --delete yansımayı kaynakla senkronize tutar. rsync tek başına sürüm geçmişi tutmaz, bu yüzden birçok ekip onu restic veya borg ile birleştirir.

Zamanlamayı cron ile Otomatikleştirin

Çalıştırmayı hatırlamanız gereken bir yedekleme, gerçekleşmeyecek bir yedeklemedir. Adımlarınızı bir betiğe koyun, onu çalıştırılabilir yapın ve cron ile zamanlayın. crontab'ınızı şu şekilde düzenleyin:

crontab -e

Ardından şu gibi satırlar ekleyin:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

Çıktıyı günlüğe kaydedin ve betiğin arıza durumunda sıfırdan farklı çıkmasını sağlayın, böylece planınızla birlikte gelen izleme ve uyarı özelliklerine bağlayabilirsiniz. Sessiz bir yedekleme arızası, yedek olmamasından daha kötüdür, çünkü güvenli hissettirir.

Gerçek Bir Site Dışı Kopya Saklayın

3-2-1'deki "1", çoğu kişinin atladığı kısımdır. Koruduğu sunucunun üzerinde duran bir yedek, o sunucuyla birlikte kaybolur. Bağımsız bir yere şifreli bir kopya gönderin — nesne depolama, uzak bir SFTP kutusu veya başka bir sağlayıcı. restic ve borg, örneğin SFTP üzerinden doğrudan uzak depolara yazar:

restic -r sftp:[email protected]:/backups/restic backup /var/www

restic ve borg, veriler VPS'nizden çıkmadan önce şifrelediğinden, uzak ana bilgisayar düz metninizi asla görmez. Eski anlık görüntüleri bir politikayla budayın, böylece depolama sonsuza dek büyümez:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Geri Yüklemelerinizi Test Edin — Her Zaman

Test edilmemiş bir yedek, bir söylentidir. Tek kullanımlık bir konuma periyodik geri yükleme zamanlayın ve dosyaların ve veritabanlarının bozulmadan geri geldiğini doğrulayın:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

Geri yükleme başarılı olur ve veriler eşleşirse, bir stratejiniz var demektir. Eğer eşleşmezse, bunu gerçek bir kesinti sırasında değil, bir Salı öğleden sonra öğrenmişsinizdir.

Anlık Görüntüler Tek Katmandır, Tüm Strateji Değil

Her ApexVPS planı otomatik yedeklemeler içerir — Starter Pro'da günlük anlık görüntüler ve Business'ta saatlik anlık görüntüler — ve kötü bir dağıtım veya yanlışlıkla silme sonrası hızlı geri almalar için gerçekten kullanışlıdırlar. Ancak ne oldukları konusunda dürüst olun: platformumuzda bulunan kullanışlı bir ilk katman. 3-2-1 kuralının gerektirdiği, bağımsız olarak doğrulanmış, site dışı kopyanın yerini tutmazlar. Platform anlık görüntülerini hızlı yerel geri yükleme noktanız olarak ele alın ve kuralın site dışı ve test edilmiş geri yükleme kısımlarını karşılamak için kendi restic veya borg işinizi çalıştırın. Bu katmanlı yaklaşım, ister Nextcloud gibi uygulamaları kendi kendinize barındırın ister bir üretim veritabanı çalıştırın, umut dolu bir kurulumu dayanıklı bir kurulumdan ayıran şeydir.

VPS Yedekleme Strateji Kontrol Listeniz

Parçaları bir araya getirirsek, sanal bir sunucu için eksiksiz bir yedekleme stratejisi şöyle görünür. Bir kez üzerinden geçin, komut dosyası haline getirin ve cron'un devam ettirmesine izin verin:

• Önemli olanı belirleyin — uygulama dosyaları, veritabanı dökümleri ve /etc altındaki yapılandırma.
• Bir araç seçin — şifreli, yinelenmeyen, sürümlü yedeklemeler için restic veya BorgBackup; basit yansımalar için rsync.
• Veritabanlarını tutarlı bir şekilde dökün — mysqldump --single-transaction veya pg_dump, asla canlı dosyaların ham kopyasını almayın.
• Otomatikleştirin — komut dosyasını cron ile zamanlayın ve sıfır olmayan her çıkışta uyarı verin.
• Bir kopyayı site dışına itin — şifreli, bağımsız depolamada, makul bir saklama politikasıyla.
• Geri yüklemeleri düzenli olarak test edin — geçici bir konuma geri yükleyin ve verilerin bozulmadığını doğrulayın.

Bu altı şeyi yapın ve 3-2-1 kuralı teori olmaktan çıkıp altyapınızın dayanabileceği bir alışkanlık haline gelsin. Kurulum için harcanan ilk saat, tek kopyanızın yeni ölen diskte olduğunu olay sırasında keşfetmenin maliyetinin yanında önemsizdir.

Sık Sorulan Sorular

Sağlayıcı anlık görüntüleri bir yedekleme stratejisi sayılır mı?

Anlık görüntüler yararlı bir katmandır ancak eksiksiz bir strateji değildir. Günlük ve saatlik anlık görüntülerimiz çoğu kısa vadeli hataya karşı korur, ancak bunlar sunucunuzla aynı platformda bulunur. Tam bir 3-2-1 yedekleme stratejisi yine de kontrol ettiğiniz bağımsız, site dışı bir kopyaya ve gerçekten test ettiğiniz geri yüklemelere ihtiyaç duyar.

Bir VPS'i ne sıklıkla yedeklemeliyim?

Sıklığı, kaybetmeyi göze alabileceğiniz veri miktarıyla eşleştirin. Statik dosyalar ve yapılandırmalar günlük yedeklenebilirken, aktif veritabanları genellikle saatlik dökümleri haklı çıkarır. Yedeklemelerin asla hatırlamaya bağlı olmaması için programı otomatikleştirmek üzere cron kullanın.

VPS yedeklemeleri için en iyi araç hangisidir?

restic ve BorgBackup ikisi de mükemmeldir: yedeklemeleri yinelenir, sıkıştırır ve şifreler ve site dışı havuzları destekler. rsync basit dosya yansıtma için uygundur ve mysqldump veya pg_dump veritabanı dışa aktarmalarını halleder. Birçok kurulum, bir veritabanı dökümünü restic veya borg çalıştırmasıyla birleştirir.

Yedeklemelerimin gerçekten çalıştığını nasıl bilirim?

Geri yüklemeleri bir programa göre test edin. Geçici bir dizine geri yükleyin, dosya içeriklerini ve sağlama toplamlarını doğrulayın ve bir veritabanı dökümünü geçici bir veritabanına aktarın. Hiç geri yüklemediğiniz bir yedek, yalnızca umutlu bir tahmindir, bir kurtarma planı değil.