Veritabanları için 3-2-1 Yedekleme Stratejisi

Yedekleme konusunda ekiplerin çoğu aynı yerde durur: bir cron işi her gece mysqldump çalıştırır, çıktıyı aynı sunucudaki bir klasöre yazar ve kimse yıllardır o dosyayı geri yüklemeyi denememiştir. Bu kurulum, disk arızası dışındaki hiçbir senaryoyu kurtarmaz — sunucu tamamen kaybolursa, bir fidye yazılımı diski şifrelerse ya da birisi yanlışlıkla DROP TABLE çalıştırıp bunu iki gün sonra fark ederse elinizde hiçbir şey kalmaz. 3-2-1 yedekleme stratejisi, tam olarak bu tek noktalı bağımlılığı kırmak için ortaya çıkmış, basit ama fazlasıyla işe yarar bir kuraldır.

Bu rehberde 3-2-1 kuralını veritabanlarına özgü gereksinimlerle birlikte ele alacağız. RPO ve RTO hedeflerinizi nasıl belirleyeceğinizi, mantıksal ve fiziksel yedeğin neden ikisinin de gerektiğini, zaman noktasına geri dönüş (PITR) altyapısını MySQL ve PostgreSQL için nasıl kuracağınızı, uzak ve değiştirilemez kopyanın fidye yazılımına karşı neden tek gerçek savunma olduğunu ve en önemlisi yedeklerin çalıştığını nasıl kanıtlayacağınızı gerçek komutlarla göstereceğim.

3-2-1 Kuralı ve Veritabanlarına Özgü Kısmı#

Kural üç sayıdan oluşur: verinizin en az 3 kopyası bulunsun, bu kopyalar en az 2 farklı ortamda saklansın ve en az 1 kopya uzak bir konumda olsun. Üç kopyadan biri üretimin kendisidir, yani iki yedek kopya demektir.

Zamanla kurala iki rakam daha eklendi ve fidye yazılımı çağında bu ikisi en az ilk üçü kadar önemli: 1 kopya çevrimdışı ya da değiştirilemez (immutable) olsun ve geri yükleme testlerinde 0 hata alınsın.

Veritabanlarını sıradan dosyalardan ayıran bir nokta var: çalışan bir veritabanının veri dosyalarını olduğu gibi kopyalamak yedek değildir. Kopyalama sırasında motor bellekteki değişiklikleri diske yazmaya devam eder ve elinize tutarsız, geri yüklendiğinde bozuk çıkan bir dosya kümesi geçer. Bu yüzden yedek ya motorun kendi araçlarıyla ya da tutarlılık garantisi veren bir anlık görüntü mekanizmasıyla alınır.

Önce RPO ve RTO Belirleyin#

Yedekleme planı, teknik bir tercih olmadan önce bir iş kararıdır ve iki sayıya indirgenir.

RPO (Recovery Point Objective), en fazla ne kadarlık veri kaybını göze aldığınızdır. Gecelik yedek alıyorsanız RPO'nuz 24 saattir; öğleden sonra çöken bir sunucu, o günün tüm işlemlerini götürür.

RTO (Recovery Time Objective), sistemin ne kadar sürede tekrar ayağa kalkması gerektiğidir. 500 GB'lık bir dökümü geri yüklemek saatler sürer; RTO'nuz 1 saat ise mantıksal yedek tek başına yetmez.

Bu iki sayıyı önce iş tarafına sorun, sonra teknik çözümü ona göre kurun. Tersini yapmak, yani mevcut yedekleme yönteminize bakıp "RPO'muz 24 saat" demek, bir hedef belirlemek değil mevcut durumu meşrulaştırmaktır.

Tablodaki son iki satır, tek başına dökümle ulaşılamayacak hedefleri gösterir. Dakikalar mertebesinde RPO istiyorsanız işlem günlüğü arşivlemesi (binlog ya da WAL) zorunludur; dakikalar mertebesinde RTO istiyorsanız yedek yeterli değildir, ayakta bekleyen bir replika gerekir. Replikasyon kurulumu için MySQL replikasyon kurulumu yazısı adım adım yol gösterir.

⚠️ Önemli bir hatırlatma: replikasyon yedek değildir. Bir replika, yanlışlıkla çalıştırılan DELETE komutunu sadakatle kopyalar. Replikasyon erişilebilirlik içindir, yedek ise geçmişe dönmek için.

Mantıksal ve Fiziksel Yedek: İkisi de Gerekir#

Mantıksal yedek, veriyi SQL ifadeleri hâlinde dışa aktarır. Taşınabilirdir, sürümler arasında çalışır, tek bir tabloyu geri yüklemenize izin verir ve içine bakıp okuyabilirsiniz. Karşılığında yavaştır — hem alması hem geri yüklemesi.

# MySQL: tutarlı mantıksal yedek (InnoDB tabloları kilitlemeden)
mysqldump --single-transaction --routines --triggers --events \
          --source-data=2 --databases uygulama \
  | gzip > /yedek/uygulama-$(date +%F-%H%M).sql.gz

# --single-transaction : InnoDB'de tutarlı anlık görüntü, tablo kilitlemez
# --routines/--triggers/--events : saklı yordam, tetikleyici ve olaylar da gelsin
# --source-data=2      : dökümün başına binlog konumunu yorum olarak yazar (PITR için şart)

# PostgreSQL: özel biçimde döküm (paralel geri yükleme ve seçmeli restore sağlar)
pg_dump -Fc -Z 6 -d uygulama -f /yedek/uygulama-$(date +%F-%H%M).dump

# İçindekileri geri yüklemeden listeleyerek dökümün sağlamlığını kontrol edin
pg_restore --list /yedek/uygulama-2026-08-25-0300.dump | head -20

Fiziksel yedek, veri dosyalarının blok düzeyinde kopyasıdır. Çok daha hızlıdır ve büyük veritabanlarında tek uygulanabilir seçenektir; ancak aynı motor sürümüne geri yüklenmesi gerekir ve tek tablo seçmenize izin vermez.

# PostgreSQL: temel yedek, WAL akışıyla birlikte
pg_basebackup -D /yedek/base-$(date +%F) -Ft -z -X stream -c fast -P

# -Ft -z : sıkıştırılmış tar; -X stream : WAL'ı eşzamanlı akıt; -c fast : checkpoint'i beklet me

MySQL tarafında blok düzeyinde sıcak yedek için XtraBackup benzeri araçlar kullanılır; bunlar veritabanını durdurmadan tutarlı bir fiziksel kopya üretir.

Pratik tavsiye şudur: her ikisini de alın. Fiziksel yedek felaket kurtarma (tüm sunucuyu geri getirme) içindir; mantıksal yedek ise "geçen haftaki musteriler tablosunu geri getir" gibi seçmeli kurtarmalar ve sürüm yükseltmeleri içindir. Ayrıntılı komut seçenekleri için mysqldump ile veritabanı yedekleme ve pg_dump ile PostgreSQL yedekleme yazılarına bakabilirsiniz.

Zaman Noktasına Geri Dönüş (PITR)#

Gecelik yedek, "bugün saat 14:32'de yanlışlıkla silinen tabloyu 14:31 hâline getir" isteğine cevap veremez. Bunun için işlem günlüklerini arşivlemeniz gerekir: MySQL'de binlog, PostgreSQL'de WAL.

# MySQL: binlog'u aç ve makul bir saklama süresi ver
[mysqld]
log_bin = /var/log/mysql/mysql-bin
binlog_format = ROW
binlog_expire_logs_seconds = 604800   ; 7 gün
sync_binlog = 1
server_id = 1

# Geri dönüş: önce tam yedeği yükle, sonra binlog'u istenen ana kadar oynat
gunzip < /yedek/uygulama-2026-08-25-0300.sql.gz | mysql uygulama

mysqlbinlog --start-datetime="2026-08-25 03:00:00" \
            --stop-datetime="2026-08-25 14:31:00" \
            /var/log/mysql/mysql-bin.000042 \
  | mysql uygulama

# PostgreSQL: WAL arşivlemesi
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /wal_arsiv/%f && cp %p /wal_arsiv/%f'
archive_timeout = 300     # sessiz dönemlerde bile 5 dakikada bir segment kapat

# Geri yükleme sırasında hedef zamanı belirtme (postgresql.conf)
restore_command = 'cp /wal_arsiv/%f %p'
recovery_target_time = '2026-08-25 14:31:00+03'
recovery_target_action = 'promote'

⚠️ Burada iki kritik nokta var. Birincisi, binlog ve WAL arşivi de yedeğin parçasıdır; onları yalnızca üretim sunucusunda tutarsanız, sunucu kaybolduğunda PITR yeteneğinizi de kaybedersiniz. Arşivi de uzak kopyaya dahil edin. İkincisi, binlog dosyalarının saklama süresini belirlemezseniz disk sessizce dolar — bu, üretimde en sık karşılaşılan disk dolma sebeplerinden biridir ve nasıl çözüleceği MySQL binlog diski doldurdu yazısında ayrıntılı anlatılıyor.

Uzak Kopya, Şifreleme ve Değiştirilemez Depolama#

Yedeğin uzak kopyası, kuralın kalbidir. Aynı sunucudaki bir yedek yalnızca "yanlışlıkla sildim" senaryosunu kurtarır; aynı veri merkezindeki bir yedek yangın ya da altyapı arızasını kurtarmaz.

Fidye yazılımı senaryosu ise özellikle önemlidir, çünkü modern saldırılar önce erişebildikleri yedekleri şifreler ya da siler, sonra üretimi kilitler. Bu nedenle uzak kopyanın iki özelliği olmalıdır: yedekleme hesabının silme yetkisi olmaması ve mümkünse depolama tarafında değiştirilemezlik (object lock) uygulanması.

# Yedeği üretirken şifrele ve doğrudan uzak depoya gönder;
# diske şifresiz hâli hiç düşmesin
pg_dump -Fc uygulama \
  | openssl enc -aes-256-cbc -pbkdf2 -salt -pass env:YEDEK_ANAHTARI \
  | ssh [email protected] "cat > /depo/uygulama-$(date +%F).dump.enc"

# rsync ile uzak kopyalama: --delete KULLANMAYIN,
# üretimde silinen bir yedek uzakta da silinir
rsync -avz --partial --timeout=120 \
      /yedek/ [email protected]:/depo/veritabani/

Deduplikasyon ve şifrelemeyi birlikte yapan yedekleme araçları (restic, BorgBackup gibi) bu iş için oldukça kullanışlıdır: yalnızca değişen blokları gönderirler, depoyu şifreli tutarlar ve saklama politikasını kendileri uygularlar.

# restic örneği: şifreli depo, saklama politikası ve bütünlük kontrolü
export RESTIC_PASSWORD_FILE=/etc/restic/parola
restic -r sftp:[email protected]:/depo/restic backup /yedek/

# Saklama planı: 7 günlük, 4 haftalık, 12 aylık kopya kalsın
restic -r sftp:[email protected]:/depo/restic forget \
       --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Şifreleme parolasını komut satırı argümanı olarak vermeyin; süreç listesinde görünür ve kabuk geçmişine yazılır. Anahtar yönetiminin tamamı için veritabanında şifreleme yazısındaki anahtar yönetimi bölümüne bakın; güçlü bir parola üretmek içinse şifre üretici aracını kullanabilirsiniz.

Doğrulama: Denenmemiş Yedek Yedek Değildir#

Bu bölüm, tüm rehberin en önemli kısmı. Sektörde tekrarlanan acı gerçek şudur: yedekleme sistemlerinin önemli bir bölümü, ilk kez gerçekten ihtiyaç duyulduğu gün çalışmadığını gösterir. Sebepleri hep aynıdır — döküm boş çıkmıştır, sıkıştırma yarıda kesilmiştir, disk dolduğu için son otuz gecedir hiçbir dosya yazılmamıştır ya da kimse --routines eklemediği için saklı yordamlar yedekte yoktur.

Doğrulamayı üç katmanda yapın:

1. Var mı ve makul boyutta mı? Her yedekten sonra dosyanın varlığını ve boyutunu kontrol edin; boyut bir öncekinin çok altındaysa alarm üretin.
2. Yapısal olarak sağlam mı? Arşivi açmayı deneyin, pg_restore --list çalıştırın, gzip bütünlüğünü sınayın.
3. Gerçekten geri yükleniyor mu? Düzenli aralıklarla temiz bir sunucuya tam geri yükleme yapın ve birkaç kritik sorguyu çalıştırıp sonucu karşılaştırın.

#!/usr/bin/env bash
# yedek-dogrula.sh — her yedekten sonra çalışır
set -euo pipefail

DOSYA="$1"
MIN_BOYUT=$((50 * 1024 * 1024))   # 50 MB altı şüphelidir

[ -f "$DOSYA" ] || { echo "HATA: yedek dosyası yok: $DOSYA"; exit 1; }

BOYUT=$(stat -c %s "$DOSYA")
[ "$BOYUT" -ge "$MIN_BOYUT" ] || { echo "HATA: yedek çok küçük ($BOYUT bayt)"; exit 1; }

# Sıkıştırma bütünlüğü
gzip -t "$DOSYA" || { echo "HATA: arşiv bozuk"; exit 1; }

echo "OK: $DOSYA ($((BOYUT/1024/1024)) MB) doğrulandı"

Tam geri yükleme provasını takvime bağlayın; üç ayda bir yeterlidir ve her seferinde geçen süreyi kaydedin. O süre sizin gerçek RTO'nuzdur — kâğıt üzerindeki hedef değil.

# Prova: temiz bir veritabanına geri yükle ve sağlık kontrolü yap
createdb uygulama_prova
pg_restore -d uygulama_prova -j 4 /yedek/uygulama-2026-08-25.dump

psql -d uygulama_prova -c "SELECT count(*) FROM musteriler;"
psql -d uygulama_prova -c "SELECT max(olusturuldu) FROM siparisler;"
dropdb uygulama_prova

Saklama Planı ve İzleme#

Her yedeği sonsuza kadar saklayamazsınız; maliyet ve KVKK saklama süresi yükümlülükleri buna izin vermez. Yaygın yaklaşım kuşak temelli bir plandır: son günlerin günlük kopyaları, son haftaların haftalık kopyaları, son ayların aylık kopyaları.

Son olarak, izleme olmadan bu planın hiçbir anlamı yok. Yedekleme işi başarısız olduğunda haber vermelidir — ve daha kritiği, hiç çalışmadığında da haber vermelidir. Bunun için "son başarılı yedek zamanı"nı bir yere yazın ve o değer beklenenden eskiyse alarm üretin.

# Başarılı yedekten sonra zaman damgası bırak
date +%s > /var/lib/yedek/son_basarili

# Ayrı bir kontrol işi: 26 saatten eskiyse uyar
SON=$(cat /var/lib/yedek/son_basarili 2>/dev/null || echo 0)
if [ $(( $(date +%s) - SON )) -gt 93600 ]; then
  echo "UYARI: 26 saattir başarılı veritabanı yedeği yok" | \
    mail -s "Yedekleme alarmı" [email protected]
fi

Sık Yapılan Hatalar#

Yedeği aynı sunucuda tutmak en yaygın hatadır. Bu kurulum yalnızca yanlışlıkla silme senaryosunu kurtarır; sunucu kaybı, fidye yazılımı ve veri merkezi arızası karşısında hiçbir işe yaramaz.

Replikasyonu yedek sanmak ikinci hatadır. Replika, hatalı bir DELETE ya da DROP komutunu saniyeler içinde kopyalar. Replikasyon erişilebilirlik sağlar, geçmişe dönüş sağlamaz.

Geri yüklemeyi hiç denememek üçüncüsüdür ve en pahalıya patlayanıdır. Çalıştığını kanıtlamadığınız bir yedekleme sistemi, aslında bir umuttur. Düzenli prova yapın ve geçen süreyi ölçün.

Şemayı ve yan bileşenleri unutmak dördüncüsüdür. Saklı yordamlar, tetikleyiciler, olaylar, kullanıcı hesapları ve yetkiler varsayılan olarak dökümde bulunmayabilir. Geri yüklediğiniz veritabanının uygulamayı gerçekten çalıştırabildiğini prova sırasında doğrulayın; kullanıcı ve yetki tarafı için MySQL kullanıcı yetkileri yazısı hangi bilgilerin ayrıca saklanması gerektiğini gösterir.

Yedeği şifrelememek beşincisidir. Uzak bir depoya gönderilen şifresiz döküm, veritabanınızın tam bir kopyasıdır; o depoya erişen herkes tüm verinize erişir.

Sıkça Sorulan Sorular#

Veritabanı yedeği ne sıklıkla alınmalı#

Cevap RPO hedefinizden çıkar: en fazla ne kadarlık veri kaybını göze alabiliyorsunuz? Kişisel bir site için gecelik yedek yeterlidir. Sipariş alan bir e-ticaret sitesi için 24 saatlik kayıp kabul edilemez; orada gecelik tam yedeğin yanına sürekli işlem günlüğü arşivlemesi eklenir ve kayıp penceresi dakikalara iner. Sıklığı belirlerken sadece teknik maliyeti değil, bir günlük siparişin yeniden oluşturulamamasının iş üzerindeki etkisini de hesaba katın.

Replikasyon yedek yerine geçer mi#

Hayır. Replikasyon, üretimdeki her değişikliği replikaya olabildiğince hızlı aktarır; bu, yanlışlıkla çalıştırılan bir DELETE ya da DROP TABLE komutunu da kapsar. Hata saniyeler içinde her iki tarafta da gerçekleşir. Replikasyon donanım arızasına ve kesintiye karşı erişilebilirlik sağlar; insan hatasına, yazılım hatasına ve fidye yazılımına karşı korumaz. İkisi birbirinin alternatifi değil, tamamlayıcısıdır.

Yedeğin çalıştığını nasıl doğrularım#

Üç kademeli kontrol uygulayın. En basiti dosyanın var olduğunu ve makul bir boyutta olduğunu kontrol etmektir; ani boyut düşüşü neredeyse her zaman bir sorunun işaretidir. İkinci kademe yapısal doğrulamadır: arşiv bütünlüğünü sınayın ve döküm içeriğini listeleyin. Asıl doğrulama ise üçüncü kademededir: düzenli aralıklarla temiz bir sunucuya tam geri yükleme yapıp birkaç kritik sorguyu çalıştırın. Bu provada ölçtüğünüz süre, gerçek kurtarma sürenizdir.

Yedekleri ne kadar süre saklamalıyım#

Kuşak temelli bir plan çoğu ihtiyacı karşılar: son 7-14 günün günlük kopyaları, son 4-8 haftanın haftalık kopyaları, son 6-12 ayın aylık kopyaları. Bu yapı hem yakın geçmişe hassas dönüş sağlar hem de geç fark edilen sorunlar için derinlik verir. Süreleri belirlerken kişisel veri saklama yükümlülüklerinizi de gözden geçirin; yedeklerde tutulan kişisel veri de saklama süresi kapsamındadır ve süresiz saklanan yedekler bu açıdan risk oluşturur.

mysqldump çalışırken site yavaşlıyor, ne yapabilirim#

Öncelikle InnoDB kullanıyorsanız --single-transaction parametresini mutlaka ekleyin; bu parametre tabloları kilitlemeden tutarlı bir anlık görüntü alır ve yavaşlamanın büyük bölümünü ortadan kaldırır. İkinci adım, yedeği trafiğin en düşük olduğu saate almaktır. Kalıcı çözüm ise yedeği bir okuma replikasından almaktır; böylece üretim sunucusu hiç etkilenmez. Veritabanı boyutu büyüdükçe mantıksal dökümün maliyeti artar, bu noktada fiziksel yedeğe geçmek doğru adımdır.

Bulut depolamaya yedek göndermek yeterli mi#

Uzak kopya şartını karşılar ama tek başına yeterli değildir. Yedekleme hesabınız o depodaki dosyaları silebiliyorsa, sunucunuzu ele geçiren bir saldırgan aynı kimlik bilgileriyle yedekleri de silebilir. Bu yüzden yedekleme hesabına yalnızca yazma yetkisi verin, silme yetkisini ayırın ve mümkünse depolama tarafında değiştirilemezlik özelliğini etkinleştirin. Ayrıca dosyaları göndermeden önce şifreleyin; şifreleme anahtarını da yedekten ayrı bir yerde saklamayı unutmayın.

Kapanış#

3-2-1 kuralı, karmaşık bir yedekleme mimarisi kurmadan önce cevaplanması gereken soruları tek bir cümlede toplar: kaç kopyanız var, kaç farklı yerde duruyor ve gerçekten geri yükleyebiliyor musunuz? Aklınızda kalması gereken dört alışkanlık şunlar: en az bir kopyayı uzak ve silinemez bir yerde tutun; replikasyonu asla yedek yerine saymayın; RPO hedefiniz saatlerin altındaysa işlem günlüğü arşivlemesini kurun ve arşivi de uzak kopyaya dahil edin; ve düzenli geri yükleme provası yapıp geçen süreyi kaydedin — o süre sizin gerçek kurtarma sürenizdir.

Uzak kopyayı ve doğrulama provasını çalıştırmak için üretimden ayrı bir hedefe ihtiyacınız olur; yedekleme hizmetimiz uzak ve düzenli kopya ihtiyacını doğrudan karşılar, prova ortamı içinse ayrı bir VDS ya da bulut sunucu örneği en pratik çözümdür. Yedekleme zamanlaması, izleme alarmları ve düzenli geri yükleme testlerini kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetimiz bu döngüyü sizin adınıza işletebilir.