Sorumluluk nasıl paylaşılıyor?

Sözleşmemize göre yönetimsiz bir sunucuda sunucunun içinden siz, altındaki altyapıdan Matrax sorumludur:

Bunun pratik anlamı şu: Yanlışlıkla silinen bir klasör, bozulan bir güncelleme, fidye yazılımı ya da ele geçirilen bir sunucu durumunda verilerinizi geri getirecek olan, sizin aldığınız yedektir. Hizmetinizde aksi belirtilmişse (örneğin yönetim hizmeti aldıysanız) kapsam o hizmetin tanımındaki gibidir.

Neyi yedeklemelisiniz?

• Veritabanları: MySQL/MariaDB veya PostgreSQL verilerini dosya kopyalayarak değil, döküm (dump) alarak yedekleyin. Çalışan bir veritabanının /var/lib/mysql klasörünü kopyalamak çoğu zaman açılamayan bir yedek üretir.
• Uygulama dosyaları: Web kök dizinleri (ör. /var/www) ve kullanıcıların yüklediği dosyalar.
• Yapılandırma: /etc klasörü (web sunucusu, PHP ve SSH ayarları), SSL sertifikaları (/etc/letsencrypt), zamanlanmış görevler (crontab -l çıktısı).
• E-posta ve kontrol paneli: Sunucuda e-posta barındırıyorsanız posta kutuları; cPanel/WHM gibi bir panel kurduysanız panelin kendi yedek aracıyla alınan hesap yedekleri.

3-2-1 kuralı ve yedeğin yeri

Yaygın kabul gören kural: Verinin 3 kopyası, 2 farklı ortamda, en az 1 tanesi başka bir konumda. Aynı sunucunun diskinde duran yedek yanlış silmeye karşı işe yarar; ama disk arızasında, sunucu ele geçirildiğinde ya da hizmet sona erdiğinde verilerle birlikte o da gider. Anlık görüntü (snapshot) kullanıyorsanız onu güncelleme öncesi kısa süreli bir geri dönüş noktası olarak görün; aynı altyapıda durduğu için sunucu dışı yedeğin yerine geçmez.

Mümkünse yedekleri hedefin çektiği bir düzen kurun. Yedeği gönderen sunucu ele geçirilirse, yazma yetkisini ele geçiren saldırgan uzaktaki yedekleri de silebilir; çeken düzende üretim sunucusunun yedek alanına erişimi olmaz.

Örnek: günlük yedek betiği

Aşağıdaki betik tüm veritabanlarının dökümünü, web dosyalarının ve yapılandırmanın arşivini alır, yedekleri uzak sunucuya aktarır ve yerelde yedi günden eski kopyaları siler. Root olarak /root/yedekle.sh adıyla kaydedip chmod 700 /root/yedekle.sh ile yalnız root'un erişebileceği hâle getirin.

#!/bin/bash
set -euo pipefail
GUN=$(date +%F)
KLASOR=/root/yedek/$GUN
mkdir -p "$KLASOR"

mysqldump --all-databases --single-transaction --routines --events | gzip > "$KLASOR/veritabani.sql.gz"
# tar'ın 1 çıkış kodu "dosya okunurken değişti" uyarısıdır; yedeği durdurmaz
tar -czf "$KLASOR/dosyalar.tar.gz" /var/www /etc || [ $? -eq 1 ]

rsync -a /root/yedek/ [email protected]:/yedekler/sunucu1/
find /root/yedek -mindepth 1 -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +

• Ubuntu ve Debian'da root kullanıcısı MariaDB'ye genellikle parolasız (soket kimlik doğrulamasıyla) bağlanır; parola gerekiyorsa bilgileri /root/.my.cnf dosyasına yazın. MariaDB'nin yeni sürümlerinde aynı araç mariadb-dump adıyla da bulunur.
• Uzak sunucuda bir yedek kullanıcısı açıp SSH anahtarınızı ona tanımlayın; betik böylece parola sormadan çalışır.
• Betik bilinçli olarak rsync --delete kullanmaz: Yerelde silinen bir kopya uzakta da silinmesin. Uzak taraftaki eski yedekleri orada ayrı bir zamanlanmış görevle temizleyin.

Betiği her gece 03.30'da çalıştırmak için crontab -e ile şu satırı ekleyin:

30 3 * * * /root/yedekle.sh >> /var/log/yedekle.log 2>&1

Sunucuya cPanel/WHM kurduysanız WHM'deki Yedekleme Yapılandırması (Backup Configuration) ekranından otomatik yedeği açıp Ek Hedefler (Additional Destinations) bölümünde SFTP veya S3 uyumlu bir uzak hedef tanımlayabilirsiniz. Windows sunucularda Sunucu Yöneticisi üzerinden Windows Server Backup özelliğini ekleyip yedekleri bir ağ paylaşımına alabilirsiniz.

Geri yüklemeyi sınayın

Hiç denenmemiş bir yedek, ihtiyaç anında açılmayabilir. Düzenli aralıklarla (örneğin ayda bir) bir yedeği test amaçlı bir sunucuya ya da yerel bir sanal makineye geri yükleyin. Hızlı bir bütünlük denetimi için:

gzip -t veritabani.sql.gz && echo "döküm sağlam"
tar -tzf dosyalar.tar.gz > /dev/null && echo "arşiv sağlam"

# Veritabanını geri yükleme (test sunucusunda)
gunzip < veritabani.sql.gz | mysql