MySQL Yedekleme ve Kurtarma: Kusursuz Veri Koruması için En İyi Uygulamalar

MySQL, yalın startup e-ticaret mağazalarından milyonlarca kullanıcıya hizmet veren kurumsal düzey SaaS platformlarına kadar olağanüstü bir uygulama yelpazesini destekler. Bu yaygınlıkla birlikte kaçınılmaz bir sorumluluk gelir: verileri donanım arızaları, insan hatası, yazılım hataları ve kötü niyetli saldırılara karşı korumak. Tek bir bozuk tablo veya yanlışlıkla silinen bir veritabanı, dakikalar içinde operasyonları durdurabilir, müşteri güvenini yok edebilir ve önemli mali kayıplara neden olabilir.

İşte bu nedenle güçlü bir MySQL yedekleme ve kurtarma stratejisi isteğe bağlı bir geliştirme değildir — veritabanı güvenilirliğinin tartışılmaz temelini oluşturur. Bu kılavuz, doğru yedekleme türünü seçmekten Olağanüstü Durum Kurtarma Planı oluşturmaya kadar, bu temelinin her katmanında size yol gösterir.

Mantıksal ve Fiziksel Yedeklemeler: Doğru Yaklaşımı Seçmek

Herhangi bir yedekleme stratejisindeki ilk mimari karar, mantıksal ve fiziksel yedeklemeler arasındaki temel farkı anlamaktır.

Mantıksal Yedeklemeler

mysqldump veya mysqlpump gibi araçlar tarafından oluşturulan mantıksal yedeklemeler, hem şema tanımlarını hem de satır verilerini içeren insan tarafından okunabilir SQL dosyaları üretir. Ana avantajları şunlardır:

• Taşınabilirlik MySQL sürümleri arasında ve hatta MariaDB veya Percona Server gibi uyumlu fork’lar arasında
• Ayrıntılılık — tek bir tabloyu, tek bir veritabanını veya tüm örneği yedekleyebilirsiniz
• İnceleme kolaylığı — çıktı dosyaları standart metin araçlarıyla açılabilir, aranabilir ve kısmen geri yüklenebilir

Ancak mantıksal yedeklemelerin önemli bir sınırlaması vardır: iyi ölçeklenmiş değildir. Birkaç yüz gigabaytı aşan veritabanları için, verileri dökmek ve daha sonra geri yüklemek için gereken süre operasyonel olarak kabul edilemez hale gelir. Dökümleri sırasında kilitleme davranışı, dikkatli bir şekilde yönetilmezse üretim performansını da etkileyebilir.

Fiziksel Yedeklemeler

Fiziksel yedeklemeler, MySQL’in diskte kullandığı ham ikili veri dosyalarını kopyalar — InnoDB tablespace’leri, redo günlükleri ve sistem dosyaları. Percona XtraBackup ve MySQL Enterprise Backup gibi araçlar *sıcak yedeklemeleri* destekler, yani veritabanını durdurmadan veya tablo kilitlemesi almadan tutarlı bir anlık görüntü yakalarlar.

Fiziksel yedeklemeler şu durumlar için standarttır:

• Büyük, üretim sınıfı veritabanları (yüzlerce gigabayt ile terabayt)
• Geri yükleme hızının kritik olduğu katı Kurtarma Süresi Hedefleri (RTO) olan ortamlar
• Yedekleme sırasında herhangi bir performans düşüşünün kabul edilemez olduğu yüksek trafikli sistemler

Ödün, azalan taşınabilirlik: fiziksel yedeklemeler tipik olarak belirli bir MySQL sürümüne ve depolama motoru yapılandırmasına bağlıdır ve kontrollü bir kurtarma ortamı gerektirir.

Pratik Karar Çerçevesi

Yedeklemeleri Otomatikleştirme: İnsan Hatasını Ortadan Kaldırma

Yedekleme stratejisindeki en tehlikeli hata modlarından biri, manuel yürütmeye bağımlılıktır. Bir insanın bir komutu çalıştırmayı hatırlamasına bağlı olan yedeklemeler, tam olarak ihtiyaç duyulan anda atlanacak yedeklemelerdir.

Cron ile Zamanlama

Linux tabanlı sunucularda, cron otomatik yedeklemeleri zamanlamak için standart mekanizmadır. Bir gece mantıksal yedeklemesi şöyle görünebilir:

0 2 * * * /usr/bin/mysqldump -u root -p'YourSecurePassword' production_db 
  | gzip > /backup/db-$(date +%F).sql.gz

Bu, her gece 02:00’de çalışır, çıktıyı hemen sıkıştırır ve tarih damgalı bir dosya adıyla depolar. VPS Hosting planında çalışan ortamlar için, cron tabanlı otomasyon yapılandırması basit ve oldukça güvenilirdir.

Yedekleme İşlerini İzleme

İzleme olmayan otomasyon eksiktir. Bir cron işi sessizce başarısız olabilir — dosya yazılmayabilir, MySQL kimlik bilgileri süresi dolmuş olabilir veya disk alanı tükeniş olabilir. Aşağıdaki koruma önlemlerini uygulayın:

• Merkezi günlüğe kaydetme: Her yedekleme işi için stdout ve stderr’i bir günlük dosyasına yönlendirin
• Çıkış kodu kontrolleri: Sıfır olmayan çıkış kodlarında uyarı verin
• Uyarı entegrasyonları: Yedekleme durumunu Slack, Telegram, PagerDuty veya tercih ettiğiniz izleme platformuna bağlayın
• Dosya boyutu doğrulaması: Beklenenin önemli ölçüde küçük olan bir yedekleme dosyası araştırmaya değer bir uyarı işaretidir

0 2 * * * /usr/bin/mysqldump -u root -p'YourSecurePassword' production_db 
  | gzip > /backup/db-$(date +%F).sql.gz 2>> /var/log/mysql_backup.log 
  && echo "Backup OK: $(date)" >> /var/log/mysql_backup.log 
  || echo "Backup FAILED: $(date)" | mail -s "MySQL Backup Failure" admin@yourdomain.com

Depolama Stratejisi: 3-2-1 Kuralı

Yedeklerinizi nerede depoladığınız, bunları nasıl oluşturduğunuz kadar önemlidir. Yedekleri üretim veritabanınızla aynı fiziksel sunucuda depolamak, veritabanı yönetiminde en yaygın ve yıkıcı hatalardan biridir. Eğer o sunucu bir donanım arızası, yangın veya fidye yazılımı saldırısı yaşarsa, hem birincil verileriniz hem de yedekleriniz aynı anda kaybolur.

3-2-1 Yedekleme İlkesi

Yedek depolama için endüstri standardı çerçeve 3-2-1 kuralıdır:

• 3 veri kopyası (1 üretim + 2 yedek)
• 2 farklı depolama ortamı türü (örn. yerel disk + bulut nesne depolama)
• 1 kopyası şirket dışında veya coğrafi olarak ayrı bir konumda depolanmış

Şirket dışı depolama için, bulut nesne depolama hizmetleri ölçeklenebilir, uygun maliyetli seçenekler sağlar:

• Amazon S3 — olgun, özellik açısından zengin, otomatik arşivleme için yaşam döngüsü politikaları ile
• Google Cloud Storage — güçlü tutarlılık garantileri ve rekabetçi fiyatlandırma
• Backblaze B2 — S3 uyumlu API ile uygun maliyetli alternatif

rclone veya s3cmd gibi araçlar, yedek dosyalarının oluşturulduktan hemen sonra bulut depolamaya aktarılmasını otomatikleştirebilir.

Saklama Politikaları

Depolama maliyetlerini kurtarma esnekliğine karşı dengelemek için açık bir saklama politikası tanımlayın:

• Günlük yedekler: 7–14 gün boyunca saklanır
• Haftalık yedekler: 4–8 hafta boyunca saklanır
• Aylık yedekler: 6–12 ay boyunca saklanır

S3 veya eşdeğer hizmetlerdeki otomatik yaşam döngüsü kuralları, bu politikaları manuel müdahale olmadan uygulayabilir.

Yedekleri Şifreleme: Verilerinizi Koruma

Üretim verilerini içeren bir yedek dosyası yüksek değerli bir hedef olabilir. Bu dosya şifreleme olmadan depolanırsa ve yetkisiz bir taraf tarafından erişilirse — yanlış yapılandırılmış bir depolama alanı, tehlikeye atılmış bir bulut hesabı veya fiziksel hırsızlık yoluyla — sonuçlar ciddi olabilir ve GDPR, HIPAA veya PCI DSS kapsamında düzenleyici cezalara neden olabilir.

Tüm yedek dosyaları depolamaya aktarılmadan önce veya aktarılırken şifrelenmesi gerekir.

GPG ile Şifreleme

GPG (GNU Privacy Guard) yedek dosyaları için güçlü simetrik veya asimetrik şifreleme sağlar:

# Symmetric encryption with passphrase
gpg --symmetric --cipher-algo AES256 db-2025-08-28.sql.gz

# Asymmetric encryption with a public key (preferred for automation)
gpg --encrypt --recipient backup@yourdomain.com db-2025-08-28.sql.gz

Asimetrik şifreleme, bir parolayı bir komut dosyasına gömmeyi gerektirmediği için otomatik işlem hatlarında tercih edilir.

Ek Güvenlik Önlemleri

• Şifreleme anahtarlarını yedek dosyalarından ayrı olarak depolayın — asla aynı konumda değil
• Bulut depolama sağlayıcıları tarafından sunulan sunucu tarafı şifreleme özelliklerini ikinci bir katman olarak kullanın
• Şifreleme anahtarlarını düzenli olarak döndürün ve güvenli bir anahtar yönetimi süreci uygulayın
• Barındırma ortamınızın kendisinin güvenli olduğundan emin olun; MySQL’i bir Dedicated Server üzerinde çalıştırıyorsanız, yedek depolama dizinlerine erişimi kısıtlayan güvenlik duvarı kuralları uygulayın

Kurtarma Testleri: En Çok Göz Ardı Edilen En İyi Uygulama

Birçok veritabanı yöneticisinin karşı koymaktan kaçındığı rahatsız edici bir gerçek vardır: hiçbir zaman başarıyla geri yüklenmemiş bir yedek, yedek değildir — yalnızca yanlış bir güvenlik hissidir.

Yedek dosyalar bozulabilir, eksik olabilir veya hedef MySQL sürümüyle uyumsuz olabilir. Yalnızca dokümantasyonda var olan ve hiçbir zaman uygulanmamış kurtarma prosedürleri, gerçek bir kesinti baskısı altında başarısız olacaktır.

Kurtarma Testi Sıklığını Belirleme

• Aylık: Hazırlık veya özel bir test sunucusunda tam geri yükleme tatbikatı gerçekleştirin
• Büyük şema değişikliklerinden sonra: Yedeklerin yeni yapıyı doğru şekilde yakaladığını doğrulayın
• MySQL sürüm yükseltmelerinden sonra: Yedek uyumluluğunu yeni sürümle onaylayın

Minimum Kurtarma Doğrulama Kontrol Listesi

-- 1. Restore backup to a fresh MySQL instance
mysql -u root -p test_restore_db < db-2025-08-28.sql

-- 2. Validate table structure and indexes
CHECK TABLE users;
CHECK TABLE orders;
CHECK TABLE products;

-- 3. Verify row counts against expected values
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM orders;

-- 4. Spot-check critical data
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;

Teknik doğrulamanın ötesinde, şunları ölçün:

• Gerçek RTO: Tam geri yükleme işlemi ne kadar sürdü? Tanımlanan Kurtarma Süresi Hedefi’nizi karşılıyor mu?
• Gerçek RPO: Yedek zaman damgası ile simüle edilen hata noktası arasında ne kadar veri kayboldu? Kurtarma Noktası Hedefi’nizi karşılıyor mu?

Bu alıştırmalar, gerçek bir felaket sırasında ortaya çıkmadan önce hem teknik boşlukları (bozuk dosyalar, eksik bağımlılıklar) hem de prosedürel boşlukları (belirsiz runbook’lar, eksik kimlik bilgileri) ortaya çıkarır.

MySQL Replikasyonu: Tamamlayıcı Bir Araç, Değil Bir Yedek Çözümü

MySQL replikasyonu — ister klasik kaynak-yineleme (eski adıyla ana-köle), yarı-senkron veya Grup Replikasyonu olsun — yüksek kullanılabilirlik ve okuma ölçeklemesi için güçlü bir araçtır. Ancak, replikasyonun *sağlamadığını* anlamak kritik derecede önemlidir: bu bir yedek çözümü değildir.

Replikasyon Neden Yedeklerin Yerini Alamaz

Replikasyon, kaynaktan yinelemelere yapılan her değişikliği neredeyse gerçek zamanlı olarak yayar. Bu şu anlama gelir:

• Kaynakta yanlışlıkla çalıştırılan bir DROP TABLE saniyeler içinde tüm yinelemelere yayılır
• WHERE yan tümcesi olmayan bir toplu DELETE müdahale edilmeden önce yayılır
• Sessiz replikasyon hataları, yinelemeleri bariz uyarılar olmadan saatler veya günler geride bırakabilir
• Depolama motoru düzeyindeki bozulma, tespit edilmeden önce yayılabilir

Optimal Birleştirilmiş Strateji

Replikasyonu *kullanılabilirlik* için yedeklerle *dayanıklılık* için birleştirmek, her iki dünyanın da en iyisini sağlar: birincil düğüm başarısız olduğunda hızlı yük devretme ve veri bozulması veya insan hatası oluştuğunda temiz bir duruma geri alma yeteneği.

Felaket Kurtarma Planlaması: Teknik Yürütmenin Ötesinde

Teknik olarak sağlam bir yedekleme sistemi gereklidir ancak yeterli değildir. Resmi bir Felaket Kurtarma Planı (DRP) olmadan, mükemmel yedekleme altyapısına sahip kuruluşlar bile bir kesinti sırasında kimin ne yapacağını ve yedeklemelerin gerçekte nerede olduğunu koordine etmeye çalışarak kritik zamanı boşa harcayabilir.

MySQL DRP’nin Temel Bileşenleri

1. Sistem Envanteri ve Önceliklendirme

Ortamınızdaki her MySQL örneğini belgeleyin. Her birini kritikliğe göre sınıflandırın: hangi veritabanları önce geri yüklenmelidir ve hangiler bekleyebilir?

2. Kurtarma Noktası Hedefi (RPO)

Her sistem için maksimum kabul edilebilir veri kaybını tanımlayın. Bir finansal işlem veritabanı için bu sıfır olabilir (senkron çoğaltma gerektirir). Bir içerik yönetim sistemi için bir saat kabul edilebilir olabilir.

3. Kurtarma Süresi Hedefi (RTO)

Maksimum kabul edilebilir kapalı kalma süresini tanımlayın. Bu, doğrudan yedekleme stratejinizi belirler: RTO’nuz 15 dakika ise, 500 GB veritabanının mantıksal bir yedek geri yüklemesi uygulanabilir değildir — fiziksel yedeklemeler ve potansiyel olarak sıcak bir yedek gerekir.

4. Roller ve Sorumluluklar

Açıkça atayın:

• Bir felaketi ilan etmeye ve kurtarmayı başlatmaya yetkili olan kişi
• Teknik geri yükleme prosedürünü yürüten kişi
• Paydaşlara durumu ileten kişi
• Yedekleme kimlik bilgilerinin ve şifreleme anahtarlarının nerede saklandığı ve kimin erişimi olduğu

5. Runbook’lar

Düz dilde yazılmış, düzenli olarak test edilen ve güncellenen adım adım kurtarma prosedürleri. Bir runbook, yalnızca onu orijinal olarak yazan kişi tarafından değil, herhangi bir yetkin sistem yöneticisi tarafından yürütülebilir olmalıdır.

6. İletişim Planı

Bir veri kaybı olayı sırasında müşterilere, dahili takımlara ve varsa düzenleyici kuruluşlara nasıl ve ne zaman bildirileneceğini tanımlayın.

Kaçınılması Gereken Yaygın MySQL Yedekleme Hataları

Deneyimli ekipler bile bu hataları yapıyor. Bunları tanımak, onları ortadan kaldırmanın ilk adımıdır.

MySQL Güvenilirliği için Doğru Hosting Ortamını Seçmek

Yedekleme ve kurtarma stratejiniz, üzerinde çalıştığı altyapı kadar güvenilirdir. MySQL’i güvenilir, iyi yapılandırılmış bir sunucuda barındırmak, bu kılavuzdaki diğer her şeyin ön koşuludur.

• Geliştirme ortamları veya daha küçük uygulamalar için, Shared Web Hosting uygun maliyetli bir başlangıç noktası sağlar, ancak yedekleme kontrolü daha sınırlıdır.
• Tam root erişimi, özel yedekleme betikleri ve özel kaynaklar gerektiren üretim MySQL dağıtımları için, VPS Hosting esneklik ve maliyet arasında doğru dengeyi sunar.
• Performans ve yalıtımın vazgeçilmez olduğu yüksek hacimli, görev açısından kritik veritabanları için, Dedicated Servers depolama, I/O performansı ve güvenlik yapılandırması üzerinde maksimum kontrol sağlar.
• Birden fazla veritabanını yönetiyorsanız veya yedekleme araçlarınızın yanında yönetim için grafik bir arayüzü tercih ediyorsanız, cPanel ile VPS düşünün; bu, yedekleme planlamasını doğrudan kontrol paneline entegre eder.

MySQL ortamınızı güvence altına almak, aynı zamanda etki alanınız ve iletişim altyapınızı da kapsar. Veritabanı yönetici arayüzlerini geçerli SSL Certificates ile korumak, kimlik bilgileri ve aktarımdaki verilerin uçtan uca şifrelendiğini sağlar.

Sonuç

Etkili bir MySQL yedekleme ve kurtarma stratejisi oluşturmak, tek bir araç seçip işi bitirmekle ilgili değildir. Her bileşenin diğerlerini güçlendirdiği katmanlı, dayanıklı bir sistem inşa etmekle ilgilidir:

• Mantıksal yedeklemeler daha küçük sistemler ve göçler için taşınabilirlik ve ayrıntılılık sağlar
• Fiziksel yedeklemeler büyük üretim veritabanları için gereken hız ve tutarlılığı sunar
• Otomasyon ve izleme insan hatasını ortadan kaldırır ve yedeklemelerin güvenilir bir şekilde gerçekleşmesini sağlar
• 3-2-1 depolama stratejisi altyapı düzeyinde tek hata noktalarına karşı koruma sağlar
• Şifreleme depolama alanı tehlikeye girse bile yedek verilerinin korunmasını sağlar
• Düzenli kurtarma testleri yedeklemelerinizin gerçekten gerekli olduğunda kullanılabilir olduğunu doğrular
• Replikasyon yedeklemeleri tamamlar ve dayanıklılığın yerini almaz, yüksek kullanılabilirlik sağlar
• Resmiyet kazanmış bir DRP ekibinizin baskı altında即興 yapmak yerine kararlı bir şekilde hareket etmesini sağlar

Birlikte uygulandığında, bu uygulamalar MySQL yedeklemesini bir kontrol listesi alıştırmasından gerçek bir güvenlik ağına dönüştürür — veritabanlarınızın bunlara bağlı olan her uygulamanın güvenilir bir temeli olarak kalmasını sağlar.