Tam olarak ne kopyalanmalı

Makinenin otomatik yedeklerini biz almıyoruz: panelde de durum anlık görüntüleri yok ve işletim sistemini yeniden kurmak diski tamamen siler. Yani yedekler tamamen senin sorumluluğunda ve bir kayıp yaşadıktan sonra değil, ilk günden başlaman gerekiyor.

Neleri yedeklemen gerekir

• Uygulama verileri — Docker volume'ları, site dizinleri, kullanıcıların yüklediği dosyalar.
• Veritabanı dökümleri — canlı veritabanı dosyaları değil, özellikle dökümler (aşağıda daha fazlası var).
• Yapılandırma — /etc/nginx, /etc/caddy, systemd unit'leri, compose.yaml ve .env dosyaları, güvenlik duvarı kuralları.
• Sertifikalar ve anahtarlar — /etc/letsencrypt, uygulama anahtarları, posta sunucusu DKIM anahtarları.
• Zamanlanmış görevler — yedeklemeden önce crontab -l > /root/crontab.txt, yoksa zamanlama dışında her şeyi geri yüklersin.
• Kurulu paketlerin listesi — dpkg --get-selections > /root/packages.txt. Kilobayt tutar, saatler kazandırır.

Yedeklemene gerek olmayan şeyler

İşletim sistemi, paketler ve Docker imajları yeniden kurulum ve komut çalıştırmayla geri gelir — yer ve zaman harcamaya değmez. /proc, /sys, /dev, /var/lib/docker klasörlerini tamamen, önbellek dizinlerini veya takas dosyalarını yedekleme.

Makul bir kural: bir yedek, internette olmayan ve talimatlarla yeniden oluşturamayacağın her şeyi içermelidir.

Veritabanları

Çalışan bir veritabanının dosyalarını kopyalayamazsın: yazma işleminin ortasında alınmış ve açılmayabilecek bir anlık görüntü elde edersin. Doğru yol, veritabanının kendi araçlarıyla döküm almaktır.

docker compose exec -T db pg_dump -U postgres app | gzip > /backup/app-$(date +%F).sql.gz
docker compose exec -T db mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --single-transaction app | gzip > /backup/app-$(date +%F).sql.gz
sqlite3 /data/app.db ".backup '/backup/app-$(date +%F).db'"

PostgreSQL ve MySQL için servisi durdurmana gerek yok. SQLite için cp değil .backup kullan: dosyayı çalışırken kopyalamak bozuk bir veritabanı üretir.

Hiç geri yükleme yapmadığın bir yedek, yedek sayılmaz. Boş bir makinede veya ayrı bir container'da test et — bkz. geri yükleme tatbikatı.

Eksiksiz bir set örneği

#!/bin/bash
set -euo pipefail
DEST=/backup/$(date +%F)
mkdir -p "$DEST"

docker compose -f /opt/myapp/compose.yaml exec -T db pg_dump -U postgres app | gzip > "$DEST/db.sql.gz"
tar czf "$DEST/etc.tar.gz" /etc/nginx /etc/letsencrypt /opt/myapp/compose.yaml /opt/myapp/.env
tar czf "$DEST/uploads.tar.gz" /var/www/uploads
crontab -l > "$DEST/crontab.txt"
dpkg --get-selections > "$DEST/packages.txt"

Betiği /usr/local/bin/backup.sh konumuna koy, chmod 700 izinlerini ver ve zamanlamaya ekle. Sonra yedeği başka bir konuma göndermen gerekir — verinin yanındaki bir dosya seni hiçbir şeyden korumaz.

Ne kadar saklamalı

Basitleştirilmiş haliyle “3-2-1” kuralı: en az iki kopya, en az biri bu makinenin dışında. Saklama için yedi günlük, dört haftalık ve üç aylık yeterli — bu, hemen fark etmediğin sessiz bir arızanın öncesindeki duruma dönmen için yeterlidir.

Yerini önceden planla: VDS-1'de 40 GB disk var ve yedek geçmişini orada saklayacak yer yok — bkz. disk alanı.

Sık yapılan hatalar

• Yedek aynı makinede. Bir yeniden kurulum, erişim kaybı, bir rm -rf hatası — ve yedek verilerle birlikte gider.
• .env dosyasını unuttun. Veriler sende ama şifreler ve anahtarlar kayboldu.
• Veritabanı volume'unu çalışırken kopyalamak. Geri yükleme bozuk bir dosyada başarısız olur. Sadece dökümler.
• Yedeğin oluşturulmayı bıraktığını kimse bilmiyor. Uptime Kuma içinde bir push kontrolü kur: betik başarıdan sonra bir adrese ping atar ve bir günlük sessizlik uyarı tetikler.