VDS Yedeği Nasıl Alınır? Sunucunun Tam Yedeğini Alma Rehberi

VDS yedeği nasıl alınır sorusu, paylaşımlı hostingten sanal sunucuya geçen herkesin ilk haftasında karşısına çıkar. Panelde alışık olduğunuz "Tam Yedekleme" düğmesi artık yoktur; karşınızda boş bir kabuk penceresi ve "yedekten sen sorumlusun" gerçeği vardır. Türkçe kaynakların çoğu bu noktada ya tek bir aracı anlatıp geçer ya da "sağlayıcının snapshot özelliğini kullanın" der. İkisi de eksiktir: araç bilmek ne yedekleyeceğinizi söylemez, snapshot da yedek değildir.

Bu rehberde bir Linux sunucusunda tam yedeğin hangi parçalardan oluştuğunu çıkarıyoruz. Web dosyaları ve veritabanı yalnızca ilk iki maddedir; asıl sunucuyu sunucu yapan şey /etc altındaki yapılandırmalar, web sunucusu site tanımları, cron tabloları, systemd birimleri, SSL sertifikaları ve anahtarları, kullanıcı hesapları, güvenlik duvarı kuralları ve posta dizinleridir. Bunların hiçbiri public_html klasörünün içinde değildir ve hiçbiri site yedeğine dâhil olmaz. Aşağıda her parçayı, neden gerektiğini ve nasıl alınacağını komutlarıyla birlikte bulacaksınız; sonunda da yedeği sunucu dışına çıkarmanın ve gerçekten çalıştığını doğrulamanın yolu var.

Panel Butonu Neden Yok: Yönetimsiz Sunucuda Sorumluluk Sınırı#

Yönetimsiz bir VDS'te sağlayıcı size donanımı, ağı ve sanallaştırma katmanını verir; işletim sisteminin içi tamamen size aittir. Bu, esneklik kazandığınız yerdir ama aynı zamanda yedeğin de sizin işiniz olduğu yerdir.

Bu farkı somutlaştıralım:

Sağ sütundaki her satır, yedeğe elle eklemeniz gereken bir kalemdir. VDS'in ne olduğunu ve hangi işler için doğru seçim olduğunu henüz netleştirmediyseniz vds nedir nasıl alınır yazısı temel çerçeveyi kuruyor.

Snapshot Yedek Değildir#

Sağlayıcı panelindeki snapshot özelliği çok işe yarar ama yedek yerine geçmez. Snapshot, diskin o andaki hâlinin sanallaştırma katmanında tutulan bir kopyasıdır ve genellikle aynı depolama altyapısında durur. Sunucu silinirse, hesap kapanırsa ya da depolama tarafında bir sorun çıkarsa snapshot da gider.

İkinci sorun, snapshot'ın tanecikli olmamasıdır. Üç gün önce silinen tek bir dosyayı geri almak için tüm diski geri döndürmeniz gerekir; bu da o üç gündeki tüm siparişleri, yorumları ve e-postaları silmek demektir. Üçüncü sorun ise fidye yazılımı senaryosudur: sunucuya erişen bir saldırgan çoğu zaman snapshot'ları da silebilir.

Snapshot'ı, "riskli bir güncellemeden hemen önce alınan geri dönüş noktası" olarak düşünün; yedek ise sunucudan bağımsız bir yerde duran, sürümlenmiş ve test edilmiş kopyadır. İkisinin farkını ayrıntılı karşılaştıran snapshot mı yedek mi yazısı bu ayrımı örneklerle gösteriyor. Doğru kurulum ikisini birlikte kullanır.

Bir VDS'te Tam Olarak Neyin Yedeklenmesi Gerekir#

Aşağıdaki liste, sunucuyu sıfırdan aynı şekilde ayağa kaldırmak için gereken her şeyi kapsıyor. Kendi sunucunuzda karşılığı olmayan satırları atlayın, ama önce gerçekten olmadığından emin olun.

Bu tabloyu bir kez kendi sunucunuza göre uyarlayıp bir dosyaya yazın. Yedekleme betiğiniz bu listeden üretilmelidir, aklınızda kalanlardan değil.

Web Dosyaları ve Site Köklerini Yedeklemek#

Site kökleriniz nerede olduğunu tahmin etmeyin, sunucuya sordurun. Nginx için:

grep -rhE "^\s*root\s" /etc/nginx/ | awk '{print $2}' | tr -d ';' | sort -u

Apache için:

grep -rhE "DocumentRoot" /etc/apache2/ /etc/httpd/ 2>/dev/null | awk '{print $2}' | sort -u

Bu komutlar, sunucuda gerçekten yayında olan tüm kökleri listeler — unuttuğunuz eski bir alt alan adı da dâhil. Ardından arşivleyin:

tar -czpf /yedek/web-$(date +%F).tar.gz \
  --exclude='*/cache/*' \
  --exclude='*/node_modules/*' \
  /var/www /home/*/public_html

-p bayrağı izinleri korur ve önemlidir; onsuz açtığınız arşivde dosya izinleri sıfırlanır. Önbellek ve node_modules gibi yeniden üretilebilir dizinleri dışarıda bırakmak yedeği ciddi biçimde küçültür. Arşivleme seçeneklerinin ayrıntısı için tar ve gzip arşivleme yazısına bakabilirsiniz.

Veritabanlarını Doğru Yedeklemek#

Veritabanı dosyalarını /var/lib/mysql altından kopyalamayın. Servis çalışırken bu dosyalar sürekli yazılır ve kopyaladığınız şey tutarsız, çoğu zaman geri yüklenemeyen bir ara durumdur. Doğru yöntem, veritabanı motoruna tutarlı bir döküm ürettirmektir.

Tüm veritabanlarını tek seferde almak için:

mysqldump --all-databases --single-transaction --quick \
  --routines --triggers --events \
  | gzip > /yedek/mysql-$(date +%F).sql.gz

Bayrakların her biri gereklidir: --single-transaction InnoDB tablolarını kilitlemeden tutarlı bir görüntü alır, --quick büyük tabloları belleğe sığdırmaya çalışmaz, --routines --triggers --events ise saklı yordamları, tetikleyicileri ve zamanlanmış olayları da dâhil eder. Bu son üçü unutulduğunda geri yükleme "başarılı" olur ama uygulamanın bir kısmı sessizce çalışmaz.

Kimlik bilgilerini komut satırına yazmayın; ~/.my.cnf dosyasına koyun ve izinlerini kısın:

[client]
user=yedek
password=parola

chmod 600 ~/.my.cnf

PostgreSQL kullanıyorsanız pg_dumpall ile aynı işi yaparsınız; ayrıntılar postgresql yedekleme pg_dump yazısında. MySQL tarafındaki tüm seçenekler ve geri yükleme akışı için mysqldump ile veritabanı yedekleme yazısına bakın.

/etc Altındaki Yapılandırmalar: Asıl Unutulan Kısım#

Sunucunuzu sunucu yapan şey burasıdır ve neredeyse hiçbir Türkçe rehber bunu yazmaz. Sitelerinizi ve veritabanınızı geri yüklediniz diyelim; nginx sanal sunucu tanımlarınız yoksa hiçbir site açılmaz, PHP-FPM havuz ayarlarınız yoksa uygulamalar çöker, güvenlik duvarı kurallarınız yoksa sunucu ya kapalı ya da açıktadır.

En basit ve en güvenilir yol, /etc dizininin tamamını almaktır. Boyutu genelde birkaç yüz megabaytı geçmez:

tar -czpf /yedek/etc-$(date +%F).tar.gz /etc

Ancak bu arşiv özel anahtarlar ve parola karmaları içerir; şifrelenmeden sunucu dışına çıkarılmamalıdır. Şifreleme adımını aşağıda ayrıca ele alıyoruz.

Seçici gitmek isterseniz en kritik yollar şunlardır:

tar -czpf /yedek/config-$(date +%F).tar.gz \
  /etc/nginx /etc/apache2 /etc/httpd \
  /etc/php /etc/mysql /etc/my.cnf /etc/my.cnf.d \
  /etc/ssh /etc/ssl /etc/letsencrypt \
  /etc/postfix /etc/dovecot \
  /etc/systemd/system /etc/cron.d /etc/crontab \
  /etc/hosts /etc/hostname /etc/fstab \
  /etc/passwd /etc/group /etc/shadow /etc/gshadow \
  2>/dev/null

2>/dev/null burada bilinçlidir: listede sunucunuzda bulunmayan yollar olacaktır ve tar bunları uyarı olarak bildirir; işlemi durdurmaz.

Cron Tabloları ve systemd Zamanlayıcıları#

Kullanıcı cron tabloları /var/spool/cron altındadır ve doğrudan düzenlenmemesi gereken dosyalardır. Yedek için okunabilir biçimde dışa aktarın:

for u in $(cut -f1 -d: /etc/passwd); do
  echo "### crontab: $u"
  crontab -l -u "$u" 2>/dev/null
done > /yedek/crontabs-$(date +%F).txt

Bu tek dosya, "yedeği geri yükledim ama gece işleri çalışmıyor" vakasının tamamını önler. Sistem geneli görevler /etc/crontab ve /etc/cron.d altındadır, onlar da yukarıdaki yapılandırma arşivine dâhildir. Cron sözdiziminden emin değilseniz cron görevleri linux yazısı zamanlama alanlarını tek tek açıklıyor.

Modern sistemlerde zamanlanmış işlerin bir kısmı systemd zamanlayıcılarındadır. Aktif olanları listeleyip yedeğe not düşün:

systemctl list-timers --all > /yedek/timers-$(date +%F).txt
systemctl list-unit-files --state=enabled > /yedek/enabled-units-$(date +%F).txt

İkinci komut özellikle değerlidir: sunucuyu yeniden kurduğunuzda hangi servislerin açılışta başlaması gerektiğini söyler. Bu bilgi hiçbir dosya arşivinde bulunmaz. systemd timer zamanlanmış görevler yazısı bu birimlerin nasıl yazıldığını anlatıyor.

SSL Sertifikaları, Kullanıcılar ve Erişim#

Let's Encrypt kullanıyorsanız /etc/letsencrypt dizininin tamamını alın. İçinde yalnızca sertifikalar değil, yenileme yapılandırmaları ve hesap anahtarı da vardır; hesap anahtarı olmadan yenileme geçmişiniz sıfırlanır. Ticari sertifika kullanıyorsanız .crt dosyasıyla birlikte özel anahtarı da almanız şarttır — sertifika anahtarsız işe yaramaz ve sertifika otoritesi size anahtarı yeniden veremez.

Kullanıcı hesapları için üç dosya birlikte anlam taşır: /etc/passwd (kullanıcı ve UID), /etc/group (gruplar), /etc/shadow (parola karmaları). Yalnızca birini almak yarım iş yapar. Bunlara ek olarak her kullanıcının ~/.ssh/authorized_keys dosyasını da alın; aksi hâlde geri yüklenen sunucuya kimse giremez.

tar -czpf /yedek/ssh-keys-$(date +%F).tar.gz /home/*/.ssh /root/.ssh

SSH anahtar mantığını gözden geçirmek isterseniz ssh anahtarı nasıl oluşturulur yazısı temelleri veriyor.

Güvenlik duvarı kurallarını da dışa aktarın; ufw kullanıyorsanız /etc/ufw dizini yeterlidir, doğrudan iptables kullanıyorsanız:

iptables-save > /yedek/iptables-$(date +%F).rules
ip6tables-save > /yedek/ip6tables-$(date +%F).rules

Posta Dizinleri ve Uygulama Verisi#

Sunucuda posta çalıştırıyorsanız, posta kutuları dosya sistemindedir ve boyutları sürpriz olabilir. Yaygın konumlar /var/mail, /home/kullanici/Maildir ve sanal posta kurulumlarında /var/vmail dizinleridir. Posta yedeği alırken servisi durdurmanız gerekmez, ancak kopyalama sırasında gelen bir mesajın yarım kalabileceğini bilin; bu yüzden posta yedeğini trafiğin düşük olduğu saatte planlayın.

Uygulama verisi /var/lib altında dağınık durur. Redis kalıcılığı /var/lib/redis, Docker birimleri /var/lib/docker/volumes, Elasticsearch verisi kendi dizininde. Docker kullanıyorsanız kapsayıcıların kendisini yedeklemeye çalışmayın; docker-compose.yml dosyalarınızı ve adlandırılmış birimleri yedekleyin, kapsayıcılar imajdan yeniden üretilir.

Paket Listesi ve Sistem Envanteri#

Bu adım küçük ama sunucuyu yeniden kurma süresini saatlerden dakikalara indirir. Kurulu paketlerin listesini bir dosyaya alın:

# Debian / Ubuntu
dpkg --get-selections > /yedek/paketler-$(date +%F).txt
apt-mark showmanual > /yedek/elle-kurulan-$(date +%F).txt

# RHEL / AlmaLinux / Rocky
rpm -qa --qf '%{NAME}\n' | sort > /yedek/paketler-$(date +%F).txt

Yanına birkaç envanter satırı daha ekleyin; geri kurulumda hangi sürümle uğraştığınızı hatırlamak paha biçilmezdir:

{
  hostname -f
  lsb_release -a 2>/dev/null
  uname -a
  php -v 2>/dev/null | head -1
  nginx -v 2>&1
  mysql --version 2>/dev/null
  df -h
} > /yedek/envanter-$(date +%F).txt

Yedeği Sunucu Dışına Çıkarmak#

Sunucunun kendi diskinde duran yedek, yedek değildir. Disk arızası, hesap kapanması ya da bir saldırı hepsini aynı anda alır. Yedek en az bir kopyayla sunucudan farklı bir yerde durmalıdır.

En yaygın ve en az bağımlılık gerektiren yöntem rsync ile ikinci bir makineye göndermektir:

rsync -az --delete-after \
  -e "ssh -i /root/.ssh/yedek_key -p 22" \
  /yedek/ yedekkullanici@hedef-sunucu:/depo/vds1/

Hedef tarafta anahtar tabanlı kimlik doğrulama kullanın ve o anahtarı yalnızca yedek için oluşturun. rsync seçeneklerinin tamamı ve artımlı kopyalama mantığı için rsync ile yedekleme yazısına bakın.

Sürümlü ve tekilleştirilmiş yedek istiyorsanız — ki VDS'te asıl doğru olan budur — Borg veya Restic gibi bir araç kullanın. Bunlar aynı dosyanın değişmeyen bloklarını tekrar tekrar saklamaz, uçtan uca şifreleme yapar ve "üç gün önceki hâli" gibi noktasal geri dönüşlere izin verir. Kurulum ve saklama politikası ayarları borg ile sunucu yedekleme ve restic ile yedekleme yazılarında adım adım anlatılıyor.

Şifrelemeyi atlamayın. /etc arşivi parola karmaları ve özel anahtarlar içerir; bu dosya üçüncü bir sunucuya şifrelenmeden gitmemelidir:

gpg --symmetric --cipher-algo AES256 /yedek/etc-$(date +%F).tar.gz

Basit bir saklama politikası da belirleyin: günlük yedekleri 7 gün, haftalıkları 4 hafta, aylıkları 6 ay tutmak çoğu site için dengeli bir başlangıçtır. Sınırsız yedek tutmak diski doldurur ve dolmuş bir disk yeni yedeğin alınmamasına yol açar — yani politika, aslında bir yedekleme güvenliği önlemidir.

Yedeği Test Etmek#

Hiç geri yüklenmemiş bir yedek, yedek değildir. En az üç ayda bir şu üç kontrolü yapın:

1. Arşiv okunabiliyor mu. tar -tzf yedek.tar.gz > /dev/null komutu hata vermeden bitmeli.
2. Veritabanı dökümü tam mı. zcat mysql.sql.gz | tail -5 çıktısında dökümün tamamlanma satırı görünmeli; yoksa döküm yarıda kesilmiştir.
3. Gerçekten ayağa kalkıyor mu. Geçici bir sunucuya yedeği açın, siteyi bir test adresiyle çalıştırın. Bu, tek gerçek testtir.

Üçüncü maddeyi düzenli yapan yöneticiler, felaket anında saatler değil dakikalar kaybeder. Geri yükleme sırasında karşınıza çıkabilecek hataları önceden görmek isterseniz yedeği geri yükleyince site açılmadı yazısı bu vakaları belirtiye göre sıralıyor.

Sıkça Sorulan Sorular#

VDS yedeği almak için hangi araç en iyisi#

Sürümlü, şifreli ve tekilleştirilmiş yedek isteyen çoğu VDS için Borg veya Restic en dengeli seçimdir. Bu araçlar aynı dosyanın değişmeyen bloklarını tekrar saklamadığı için günlük yedek almanın disk maliyeti çok düşük kalır ve geçmiş bir tarihe noktasal dönüş yapabilirsiniz. Yalnızca en güncel kopyayı başka bir makinede tutmak yetiyorsa rsync daha az kurulum gerektirir. Aracın seçimi ikincildir; asıl belirleyici olan neyi yedeklediğiniz ve yedeği sunucu dışına çıkarıp çıkarmadığınızdır.

Sağlayıcının snapshot özelliği yedek yerine geçer mi#

Geçmez, çünkü snapshot genellikle sunucuyla aynı altyapıda durur ve sunucu ya da hesap ortadan kalktığında o da kaybolur. Ayrıca snapshot tek bir dosyayı geri getirmeye uygun değildir; üç gün önce silinen bir dosya için tüm diski geri döndürmek, aradaki tüm yeni veriyi silmek anlamına gelir. Snapshot'ın doğru kullanımı, riskli bir güncelleme veya yapılandırma değişikliği öncesinde alınan kısa ömürlü geri dönüş noktasıdır. Gerçek yedek, sunucudan bağımsız bir konumda duran, sürümlenmiş ve geri yükleme testi yapılmış kopyadır.

Veritabanı dosyalarını doğrudan kopyalayabilir miyim#

Servis çalışırken kopyalamamalısınız, çünkü veri dosyaları sürekli yazılır ve elde ettiğiniz kopya tutarsız olur. Böyle bir kopyayı geri yüklediğinizde tablolar bozuk çıkabilir veya veritabanı hiç başlamayabilir. Doğru yöntem mysqldump veya pg_dumpall gibi araçlarla motorun kendisine tutarlı bir döküm ürettirmektir. Dosya düzeyinde kopya almanız gerekiyorsa servisi durdurmanız ya da anlık görüntü destekli bir dosya sistemi kullanmanız gerekir.

Sunucunun tamamını mı yoksa sadece verileri mi yedeklemeliyim#

Çoğu senaryoda doğru yaklaşım, veriyi ve yapılandırmayı yedeklemek, işletim sistemini ise yeniden kurmaktır. Tüm diskin imajını almak hem çok yer kaplar hem de farklı bir sunucuya geri yüklerken donanım ve sürücü uyumsuzluğu çıkarabilir. Buna karşılık /etc altındaki yapılandırmalar, cron tabloları, systemd birimleri ve paket listesi yedeklenirse, temiz bir kurulum üzerine aynı sunucuyu kısa sürede yeniden inşa edebilirsiniz. Kritik olan, bu ikinci grubun unutulmamasıdır; çoğu eksik yedek tam olarak burada eksiktir.

Yedeği ne sıklıkta almalıyım#

Sıklığı belirleyen soru şudur: kaç saatlik veriyi kaybetmeyi göze alabilirsiniz. Günde birkaç sipariş alan bir siteye günlük yedek yeterken, saatlik işlem gören bir sistemde günlük yedek bir günlük siparişi kaybetmek demektir. Pratikte yaygın kurulum, dosyalar için günlük, veritabanı için daha sık aralıklarla döküm almaktır. Sıklığı artırırken saklama politikası da belirleyin; aksi hâlde disk dolar ve dolu disk yeni yedeğin sessizce alınmamasına yol açar.

Yedek aldığımı nasıl doğrularım#

Yedekleme betiğinin çıkış kodunu kontrol edin ve sonucu bir günlük dosyasına yazdırın, ama bununla yetinmeyin. Arşivin okunabilir olduğunu tar -tzf ile, veritabanı dökümünün yarıda kesilmediğini dökümün son satırlarına bakarak doğrulayın. Asıl doğrulama ise düzenli aralıklarla yedeği geçici bir sunucuya açıp siteyi gerçekten çalıştırmaktır. Yalnızca "işlem tamamlandı" mesajına güvenmek, en sık karşılaşılan yedekleme yanılgısıdır.

Yedeği şifrelemem gerekir mi#

Yedek sunucu dışına çıkıyorsa evet, gerekir. Tam bir sunucu yedeği /etc/shadow içindeki parola karmalarını, SSL özel anahtarlarını, veritabanı kimlik bilgilerini ve SSH anahtarlarını içerir; bu dosyaya erişen biri sunucunun tamamına erişmiş sayılır. Simetrik şifreleme için gpg yeterlidir, Borg ve Restic gibi araçlar ise şifrelemeyi zaten kendi içinde yapar. Şifreleme anahtarını yedeğin durduğu yerde saklamayın; ayrı bir yerde tutun ve kaybetmeyin, çünkü anahtarsız yedek geri yüklenemez.

Yedeği aynı sunucuda tutmam yeterli değil mi#

Yeterli değildir, çünkü aynı sunucuda duran yedek, sunucuyu kaybettiren her senaryoda birlikte kaybolur. Disk arızası, hesabın kapanması, dosya sistemi bozulması veya sunucuya erişen bir saldırgan hepsinde yedek de gider. Sunucu içi kopya yalnızca "yanlışlıkla sildim" türü hatalarda hızlı geri dönüş sağladığı için değerlidir. En az bir kopyanın farklı bir makinede, tercihen farklı bir konumda bulunması yedeklemenin temel kuralıdır.

Kapanış#

Bir VDS'te tam yedek, public_html klasörünü sıkıştırmaktan ibaret değildir. Site dosyaları ve veritabanı işin görünen yarısıdır; sunucuyu yeniden ayağa kaldıran asıl bilgi /etc altındaki yapılandırmalarda, web sunucusu site tanımlarında, cron tablolarında, systemd birimlerinde, SSL anahtarlarında, kullanıcı hesaplarında ve paket listesindedir. Bu listeyi bir kez kendi sunucunuza göre çıkarıp yedekleme betiğinizi ondan üretirseniz, felaket anında elinizde eksiksiz bir kopya olur. Sonra tek bir alışkanlık kalır: yedeği düzenli olarak geri yükleyip gerçekten çalıştığını görmek.

Bu işi kendiniz yürütmek yerine devretmek isterseniz, sunucu tarafındaki yedekleme kurulumu ve saklama politikası sunucu yönetimi hizmetinin kapsamındadır. Yedeklerin sunucu dışında, sürümlü ve şifreli biçimde tutulması için yedekleme çözümümüze bakabilirsiniz. Henüz sunucu tarafını seçme aşamasındaysanız VDS paketleri sayfasında kaynak seçeneklerini, esnek ölçeklenebilirlik arıyorsanız bulut sunucu sayfasını inceleyebilirsiniz.