Dedicated sunucu için yedekleme ve geri yükleme planı

Bu rehberde ne yapacağız?

Yedek, ancak geri yüklenebildiği zaman işe yarar. Bu rehberde dedicated sunucunuz için kayıpları sınırlayan bir yedekleme ve geri yükleme planı hazırlayacaksınız: neyin yedekleneceğini belirleme, hedef ve süre kararları, basit bir betikle dosya ve veri tabanı yedeği, otomatik çalıştırma ve düzenli geri yükleme testi.

Rehber, kendi dedicated sunucusunu ya da müşteri sunucularını yöneten sistem yöneticilerine yöneliktir. Plan ve ilk kurulum yaklaşık bir saat sürer. Betikler Debian/Ubuntu ve RHEL tabanlı sistemlerde aynen çalışır; paket kurulum farkları ayrıca verilmiştir.

Gereksinimler

• Sunucuda sudo yetkisi
• Yedeklerin saklanacağı, sunucudan ayrı bir hedef: başka bir sunucu, nesne depolama veya ayrı konumdaki yedek alanı
• Yedek hedefine SSH anahtarıyla erişim
• Yeterli depolama alanı; ilk tam yedek ve artımlı büyüme için kaba bir hesap yapın
• MySQL/MariaDB veya PostgreSQL kullanıyorsanız veri tabanı erişim bilgileri

Adım adım yedekleme ve geri yükleme planı

1. Hedefleri belirleyin: RPO ve RTO

İki soruya yanıt verin. En çok ne kadar veri kaybına katlanabilirsiniz (RPO)? Sunucunun geri gelmesi en çok ne kadar sürebilir (RTO)? Cevaplar yedek sıklığını ve yöntemini belirler. Örneğin günde bir yedek, en fazla bir günlük veri kaybı demektir.

Ardından 3-2-1 kuralını hedefleyin: verinin üç kopyası, iki farklı ortam, bir kopya sunucudan uzakta.

2. Neyi yedekleyeceğinizi listeleyin

• Uygulama ve site dosyaları
• Veri tabanları (dosya kopyası değil, tutarlı döküm)
• Yapılandırma dosyaları: /etc, web sunucu, mail ve DNS ayarları
• Zamanlanmış görevler, SSL sertifikaları ve anahtarlar
• Kurulu paketlerin listesi

# Debian / Ubuntu
dpkg --get-selections > /root/paket-listesi.txt

# AlmaLinux / Rocky
rpm -qa > /root/paket-listesi.txt

3. Yedek hedefine erişimi hazırlayın

Yedek sunucusuna parolasız ve yalnızca bu iş için kullanılan bir anahtarla bağlanın.

sudo ssh-keygen -t ed25519 -f /root/.ssh/yedek_anahtar -N ''
sudo ssh-copy-id -i /root/.ssh/yedek_anahtar.pub YEDEK_KULLANICI@YEDEK_SUNUCU

4. Yedekleme betiğini yazın

Aşağıdaki betik veri tabanını dökümler, önemli dizinleri sıkıştırır ve yedek sunucusuna aktarır. Yer tutucuları kendi bilgilerinizle değiştirin. MySQL için parola, ~/.my.cnf dosyasında (izin 600) tutulmalı; betiğe düz yazılmamalıdır.

sudo nano /usr/local/sbin/yedekle.sh

#!/bin/bash
set -euo pipefail
# Yedekler /etc/shadow ve veri tabanı içerir; yalnızca root okuyabilsin
umask 077
TARIH=$(date +%F)
YEREL=/var/backups/sunucu/$TARIH
mkdir -p "$YEREL"

# Veri tabanı dökümü (MariaDB/MySQL)
mysqldump --single-transaction --all-databases | gzip > "$YEREL/veritabani.sql.gz"

# Dosyalar ve yapılandırmalar
tar -czf "$YEREL/dosyalar.tar.gz" /etc /var/www /root/paket-listesi.txt

# Uzak sunucuya aktar
rsync -a -e 'ssh -i /root/.ssh/yedek_anahtar' /var/backups/sunucu/ YEDEK_KULLANICI@YEDEK_SUNUCU:/yedekler/sunucu1/

# 14 günden eski yerel yedekleri temizle
find /var/backups/sunucu -mindepth 1 -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +

sudo chmod 700 /usr/local/sbin/yedekle.sh
sudo /usr/local/sbin/yedekle.sh

Betikte rm -rf kullanan satır yalnızca yerel yedek dizinini hedefler. Yolu değiştirirseniz çok dikkatli olun; yanlış yol veri kaybına yol açar. PostgreSQL kullanıyorsanız mysqldump satırı yerine sudo -u postgres pg_dumpall ile döküm alın. rsync --delete olmadan çalıştığı için yedek sunucusundaki eski kopyalar silinmez; orada ayrı bir saklama ve temizlik politikası uygulayın.

5. Zamanlayın

sudo crontab -e

30 3 * * * /usr/local/sbin/yedekle.sh >> /var/log/yedekle.log 2>&1

6. Geri yükleme prosedürünü yazın ve deneyin

Geri yükleme adımlarını yazılı hale getirin ve ayrı bir test makinesinde deneyin. Basit bir akış şöyledir.

# Dosyaları geçici dizine açın
mkdir -p /tmp/geri && tar -xzf dosyalar.tar.gz -C /tmp/geri

# Veri tabanını geri yükleyin (test sunucusunda)
gunzip < veritabani.sql.gz | mysql

Uyarı: Üretim sunucusunda geri yükleme yaparken mevcut veriyi ezeceğinizi unutmayın. Önce o anki durumun yedeğini alın ve mümkünse ayrı bir ortamda deneyin.

Doğrulama

Yedek dizinleri yalnızca root'a açık olduğundan aşağıdaki komutları root kabuğunda (sudo -i) çalıştırın.

ls -lh /var/backups/sunucu/
tail -n 20 /var/log/yedekle.log
gzip -t /var/backups/sunucu/*/veritabani.sql.gz
tar -tzf /var/backups/sunucu/$(date +%F)/dosyalar.tar.gz | head
ssh -i /root/.ssh/yedek_anahtar YEDEK_KULLANICI@YEDEK_SUNUCU 'ls -lh /yedekler/sunucu1'

Beklenen sonuç: Bugünün tarihli dizinin oluşması, gzip -t komutunun hatasız bitmesi, tar listesinin dosyaları göstermesi ve yedek sunucuda dosyaların bulunmasıdır. Asıl doğrulama, düzenli aralıklarla gerçek bir geri yükleme denemesidir.

Sık karşılaşılan sorunlar

• Cron betiği çalışmıyor: Cron'un PATH değişkeni kısıtlıdır. Betikte komutları tam yolla çağırın ve log dosyasını kontrol edin.
• mysqldump erişim reddi: Parola veya kullanıcı eksiktir. ~/.my.cnf dosyasını doğru kullanıcıyla oluşturun ve izinleri 600 yapın.
• Disk doluyor: Yerel saklama süresini kısaltın veya yedeği yerelde tutmadan doğrudan aktarın.
• rsync izin hatası: Yedek kullanıcısının hedef dizine yazma izni olmayabilir; dizin sahipliğini kontrol edin.
• Yedek alındı ama açılmıyor: Bozuk arşiv olasılığına karşı gzip -t ve düzenli geri yükleme testi yapın.

Güvenlik ve bakım notları

• Yedek sunucusuna yalnızca yedek işi için bir kullanıcı ve anahtar tanımlayın; mümkünse üretim sunucusu yedeği silemesin.
• Yedekleri şifreleyin (örneğin restic gibi şifreli araçlar ya da arşivi gpg ile şifreleme) ve parolayı ayrı saklayın.
• Üç ayda bir tam geri yükleme tatbikatı yapın ve süresini kaydedin.
• Yedek betiğinin başarısızlığında e-posta veya izleme uyarısı üretin.
• Fidye yazılımına karşı en az bir kopyayı değiştirilemez (immutable) ya da çevrimdışı tutun.
• Kişisel veri içeren yedeklerde KVKK saklama sürelerini ve erişim yetkilerini göz önünde bulundurun.