MySQL Veritabanı Yedekleme Stratejileri: mysqldump, Percona XtraBackup ve Snapshot Nasıl Seçilir?

MySQL Veritabanı Yedekleme Stratejilerine Doğru Yerden Bakmak

MySQL yedekleme konusu gündeme geldiğinde ilk akla gelen genelde şu olur: “Ne ile yedek alalım?” Oysa asıl soru “Ne kadar veri kaybına tahammül edebiliriz (RPO) ve sistem ne kadar süre kapalı kalabilir (RTO)?” olmalı. Eğer bu iki sorunun cevabı net değilse, mysqldump mı, Percona XtraBackup mı, snapshot mı tartışması hep havada kalır. RPO/RTO kavramlarını daha önce yedekleme stratejisi planlama rehberimizde detaylı anlattık; bu yazıda o çerçeveyi MySQL özelinde somutlaştıracağız.

Web hosting dünyasında iş biraz daha karışık. paylaşımlı hosting, yönetilen VPS, kendi yönettiğiniz VPS/dedicated ve colocation gibi çok farklı senaryolar var. Bazı ortamlarda sadece mysqldump çalıştırabilirsiniz; bazı ortamlarda Percona XtraBackup ile fiziksel yedek alabilir, bazı ortamlarda ise disk veya hypervisor snapshot’ları devreye sokabilirsiniz. DCHost tarafında günlük operasyonlarda en çok gördüğümüz sorun, bu üç yöntemin birbirinin alternatifi sanılması. Aslında çoğu gerçekçi mimaride bunlar birbirini tamamlıyor.

Bu yazıda mysqldump, Percona XtraBackup ve snapshot tabanlı yedekler arasındaki farkları; hangi hosting ortamında hangisinin mantıklı olduğunu; bunları RPO/RTO hedeflerinizle nasıl eşleştireceğinizi adım adım konuşacağız. Sonunda, DCHost üzerinde çalışan MySQL veritabanlarınız için pratik bir karar şablonuna sahip olacaksınız.

Web Hosting’de MySQL Yedekleme Yaklaşımları: Mantıksal, Fiziksel ve Snapshot

Önce büyük resmi netleştirelim. MySQL yedeklerini kabaca üç farklı yaklaşımla alabilirsiniz:

• Mantıksal yedekler (mysqldump, mydumper vb.)
• Fiziksel yedekler (Percona XtraBackup gibi araçlarla dosya seviyesinde kopya)
• Depolama/sistem snapshot’ları (LVM, ZFS, hypervisor veya storage katmanında snapshot)

Her yaklaşımın kendine göre güçlü ve zayıf tarafları var. En kritik noktalar:

• Tutarlılık: Yedeğin geri döndüğünde çalışır ve tutarlı olması.
• Performans etkisi: Yedek alırken canlı sisteme verdiği yük.
• Geri dönüş hızı (restore süresi): Felaket anında ne kadar hızlı ayağa kalkabildiğiniz.
• Operasyonel karmaşıklık: Kurulum, izleme ve test zorluğu.

Bu üç yöntemi karşılaştırırken sadece “hangisi daha iyi” diye bakmak yerine, hangi ortamda hangisi birincil yöntem, hangisi tamamlayıcı yöntem olmalı diye düşünmek çok daha sağlıklı. Zaten MySQL/MariaDB yedekleme stratejileri yazımızda da vurguladığımız gibi, ciddi projelerde tek araca yaslanmak neredeyse hiç iyi fikir değil.

mysqldump: Paylaşımlı Hosting ve Küçük Veritabanları İçin Klasik Çözüm

mysqldump, MySQL ile birlikte gelen, mantıksal (logical) yedek alan bir araçtır. Temel mantığı, veritabanını SQL komutları (CREATE TABLE, INSERT vb.) olarak dışa aktarmak ve bunları bir .sql dosyasında toplamak. Bu dosyayı daha sonra başka bir MySQL sunucusuna import ederek veritabanını yeniden oluşturabilirsiniz.

mysqldump’ın Artıları

• Her yerde çalışır: Paylaşımlı hosting, yönetimli VPS, root yetkisi olmayan ortamlarda bile kullanılabilir.
• Versiyon esnekliği: Genelde daha yeni bir MySQL sürümüne import etmek kolaydır; fiziksel yedeklerdeki “minor sürüm uyumsuzluğu” dertleri burada daha az.
• Tablo/şema seviyesi esneklik: Sadece belirli tabloları, şemaları veya veriyi filtreleyerek yedeklemek mümkündür.
• Okunabilirlik: Yedek düz SQL olduğu için gerektiğinde dosya üzerinden inceleme, arama, manuel düzeltme yapılabilir.

mysqldump’ın Eksileri

• Yavaş restore: Geri yükleme sırasında her INSERT tek tek çalıştığı için büyük veritabanlarında restore süresi uzar.
• Yüksek CPU/IO tüketimi: Özellikle büyük veritabanlarında hem export hem import sırasında ciddi kaynak kullanır.
• Büyük verilerde ölçeklenme sorunu: 50–100 GB üstü InnoDB veritabanlarında artık mantıksal yedek pratik olmaktan çıkar.

Paylaşımlı Hosting’de mysqldump Nasıl Kullanılır?

Paylaşımlı hosting kullanıyorsanız eliniz çoğu zaman zaten mysqldump + panel yedekleri ile sınırlıdır. Genelde iki yol vardır:

• Kontrol panelinin (cPanel, DirectAdmin vb.) sunduğu otomatik veritabanı yedeklerine güvenmek.
• Ek olarak periyodik bir mysqldump çalıştırıp yedeği ayrı bir depolamaya aktarmak (cron + uzak FTP/S3 vb.).

Basit bir tam yedek örneği şu şekilde olabilir:

mysqldump -u USER -p 
  --single-transaction 
  --routines --events 
  --databases VERITABANI_ADI 
  | gzip > backup-$(date +%F).sql.gz

--single-transaction parametresi InnoDB tablolar için tutarlı bir anlık görüntü sağlar ve FLUSH TABLES WITH READ LOCK kullanmaya göre çok daha az kilit problemi yaşarsınız.

mysqldump Ne Zaman Yeterli?

Aşağıdaki koşullar sağlanıyorsa mysqldump genellikle tek başına idare eder:

• Toplam veritabanı boyutu 5–10 GB civarında veya altında.
• RPO hedefiniz saatlik veya günlük seviyede ve çok kritik değil (ör. içerik/blog siteleri).
• Restore olduğunda birkaç saatlik kesinti tolere edilebilir.
• Paylaşımlı hosting kullanıyor ve root yetkisine sahip değilsiniz.

Buna karşılık, yüksek trafikli bir WooCommerce mağazası, yoğun kullanılan bir SaaS ürünü veya finansal verilerin bulunduğu kritik sistemler için mysqldump’ı tek bacak yapmanızı önermeyiz; burada işin içine mutlaka fiziksel yedekler ve/veya snapshot’lar girmeli.

Percona XtraBackup: Büyük MySQL Yükleri İçin Fiziksel Yedek

Percona XtraBackup, özellikle InnoDB motoru için tasarlanmış, sıcak (hot) fiziksel yedek aracı. Temel farkı şu: mysqldump veritabanını SQL komutlarına çevirirken, XtraBackup doğrudan MySQL’in veri dosyalarını (ibdata, ibd dosyaları, redo log vb.) kopyalar. Bunu da veritabanı çalışırken, minimum kilitleme ile yapar.

Percona XtraBackup’ın Güçlü Yanları

• Hızlı yedek ve hızlı geri dönüş: Dosya seviyesinde kopyalama yaptığı için hem backup hem restore süresi büyük veritabanlarında mantıksal yedeklere göre çok daha kısadır.
• InnoDB için neredeyse sıfır kesinti: Yedekleme sırasında sadece kısa süreli metadata kilitleri gerekir; canlı trafik büyük ölçüde devam eder.
• Artımlı (incremental) yedek desteği: Günlük tam yedek + saatlik incremental gibi kurgularla depolama ve trafik maliyetini düşürebilirsiniz.
• Point-in-Time Recovery (PITR) entegrasyonu: Binary log ile birleştiğinde saniye hassasiyetinde geri dönüş senaryoları kurulabilir.

Percona XtraBackup’ın Zayıf Noktaları

• Kurum ve yönetim daha karmaşık: Özellikle ilk seferde prepare, restore, kullanıcı izinleri ve versiyon uyumluluğu gibi detayları doğru oturtmak gerekiyor.
• Root/OS yetkisi ister: Paylaşımlı hosting’lerde genelde kullanamazsınız; VPS/dedicated veya colocation ortamı gerekir.
• Disk layout bağımlılığı: Aynı MySQL major/minor sürümü, benzer konfigürasyon (innodb_page_size vb.) gibi konulara dikkat edilmezse restore süreci sancılı olabilir.

Hangi Hosting Ortamında XtraBackup Mantıklı?

XtraBackup, daha çok şu senaryolara yakışır:

• DCHost üzerinde kendi yönettiğiniz VPS veya dedicated sunucular.
• Disk alanınız ve IO’nuz nispeten bol; cron ile gece/gündüz periyodik yedek alabiliyorsunuz.
• Veritabanı boyutunuz onlarca GB seviyesine gelmiş ve mysqldump ile restore süreleri artık saatleri buluyor.
• WooCommerce, Laravel veya özel yazılım gibi, veritabanı trafiği yoğun, RPO/RTO hedefleri görece sıkı projeler.

Örneğin DCHost üzerinde çalışan 80 GB’lık bir WooCommerce veritabanında; gecelik tam XtraBackup, saatlik incremental ve binary log arşivleme ile hem düşük RPO hem de hızlı geri dönüş elde etmek mümkün.

Basit Bir XtraBackup Senaryosu

Temel akış genelde şöyledir:

1. Gece 03:00’de tam fiziksel yedek (full backup).
2. Gün içinde her saat incremental yedekler.
3. Binary log’lar ayrı klasörde veya uzak depolamada tutulur.
4. Restore gerektiğinde; son tam yedek + ilgili incremental’ler + binary log’larla istenen ana kadar geri sarılır.

Bu mimariyi, örneğin Restic/Borg ile S3 uyumlu uzak yedekleme gibi dosya seviyesinde çözümlerle birleştirerek DCHost üzerindeki farklı veri merkezlerine veya S3 uyumlu depolamaya replikasyon yapmak da mümkün.

Snapshot Yedekleri: Milisaniyelik RPO ve Çok Hızlı Geri Dönüş

Snapshot, veritabanını değil, verinin bulunduğu disk/volume katmanını anlık donduran bir mekanizmadır. Bunu LVM, ZFS, Ceph RBD, hypervisor düzeyi snapshot veya storage sisteminin kendi snapshot özelliği ile yapabilirsiniz. DCHost tarafında özellikle NVMe tabanlı VPS ve dedicated sunucularda, LVM/ZFS snapshot’larını XtraBackup veya mysqldump ile birlikte kullanmak sık gördüğümüz bir yaklaşım.

Snapshot’ın Güçlü Yanları

• Çok hızlı: Genelde saniyeler hatta milisaniyeler içinde snapshot alınabilir; büyük verilerde bile yedek alma süresi kısalır.
• Hafif: Çoğu snapshot mekanizması copy-on-write mantığıyla çalıştığı için başlangıçta çok az ek alan kullanır.
• Hızlı geri dönüş: Özellikle aynı storage üzerinde geri dönüyorsanız, restore süresi dosya kopyalamaya göre çok daha kısa olabilir.

Snapshot’ın Tehlikeli Yanı: Tutarlılık

Snapshot tek başına sadece diskte ne varsa onu dondurur. MySQL ise RAM’de buffer pool, disk üzerinde redo log, doublewrite buffer gibi mekanizmalarla çalıştığı için, rastgele bir anda alınan snapshot crash-consistent düzeyde olur. Yani sistem sanki elektrik kesilmiş gibi kapanmış kabul edilir; çoğu durumda MySQL kendini toparlar, ama yoğun yazma yükü altında bu her zaman garantili değildir.

Bu yüzden snapshot’ları mümkün olduğunca uygulama-tutarlı hale getirmek gerekir. Bunun için tipik olarak:

• MySQL’de FLUSH TABLES WITH READ LOCK veya FLUSH TABLES ... + FLUSH LOGS gibi komutlarla yazmaları dondurmak,
• Linux tarafında fsfreeze kullanarak dosya sistemini kısa süreliğine dondurmak,
• Sonra LVM/ZFS vb. snapshot’ını alıp kilitleri bırakmak

gibi bir akış tercih edilir. Bu konuyu MySQL/PostgreSQL odaklı olarak adım adım anlattığımız uygulama-tutarlı yedekler rehberini mutlaka okumanızı öneririm.

Snapshot Yedekleri Hangi Ortamlarda Parlıyor?

Snapshot yaklaşımı özellikle şu senaryolarda çok değerli:

• DCHost üzerinde NVMe diskli VPS veya dedicated sunucuda, büyük InnoDB veritabanları tutuyorsunuz.
• RPO hedefiniz dakikalar mertebesinde; sık snapshot alıp araya incremental XtraBackup’lar yerleştirebiliyorsunuz.
• Aynı storage üzerinde saniyeler içinde test restore yapmak istiyorsunuz.

Ancak snapshot’ların çoğu zaman aynı fiziksel altyapıda tutulduğunu unutmayın. Bu nedenle snapshot, 3-2-1 prensibindeki “farklı ortamda yedek” gereksinimini tek başına karşılamaz. Snapshot’ları mutlaka ayrı bir depolamaya replikasyon (ör. S3 uyumlu storage) veya fiziksel yedekle birleştirerek düşünmek gerekir.

3-2-1 Prensibiyle Birlikte Düşünmek: Tek Araç Asla Yetmez

İş sadece “mysqldump mı, XtraBackup mı, snapshot mı” sorusuyla bitmiyor. Yedeklerinizi nerede, kaç kopya ve hangi ortamda tuttuğunuz en az araç seçimi kadar kritik. Bu noktada klasik 3-2-1 yedekleme stratejisi devreye giriyor:

• 3 kopya: Verinizin en az 3 kopyası olmalı (orijinal + 2 yedek).
• 2 farklı ortam: Bu kopyalar en az 2 farklı depolama ortamında tutulmalı (farklı disk havuzları, farklı storage sistemleri).
• 1 tanesi offsite: En az bir kopya fiziksel olarak farklı bir lokasyonda veya mantıksal olarak ayrı bir sağlayıcıda olmalı.

Bunu MySQL’e uyarladığınızda, örneğin şöyle bir kombinasyon ortaya çıkabilir:

• Seviye 1: Aynı sunucuda LVM/ZFS snapshot (çok hızlı local geri dönüş için).
• Seviye 2: Ayrı bir disk veya sunucuda Percona XtraBackup ile fiziksel yedek.
• Seviye 3: S3 uyumlu depolama üzerinde şifreli ve versiyonlu yedek (ör. Restic/Borg ile). Buraya ek olarak S3 Object Lock ile fidye yazılıma dayanıklı yedekler gibi koruma katmanları eklenebilir.

Bu prensibi hosting panelleri, VPS ve dedicated sunucular için nasıl uygulanabilir hale getirebileceğinizi 3-2-1 yedekleme stratejisi rehberimizde adım adım anlattık. MySQL yedeklerinizi planlarken o yazıyla birlikte okursanız, stratejiniz çok daha sağlam oturur.

Farklı Hosting Senaryoları İçin Pratik Karar Şablonu

Şimdi en kritik kısma gelelim: DCHost üzerinde hangi senaryoda hangi yaklaşımı birincil, hangisini tamamlayıcı yapmalısınız?

1) Paylaşımlı Hosting’de MySQL Yedekleme

Genelde kısıtlarınız şöyle olur:

• Root yetkisi yok.
• MySQL’in data dizinine erişiminiz yok.
• Disk, CPU, IO limitleri sıkı.

Bu durumda tipik strateji:

• Birincil yöntem: Hosting panelinin sağladığı otomatik veritabanı yedekleri.
• Tamamlayıcı: Günlük veya saatlik mysqldump alıp ayrı bir depolamaya göndermek (örn. uzak SFTP/S3).

Eğer MySQL veriniz 2–3 GB’tan büyükse ve iş kritikse, genelde VPS’e geçişi düşünmenin zamanı gelmiştir. Bu konuda kararsızsanız, genel perspektif için paylaşımlı hosting’den VPS’e geçiş rehberimize de göz atabilirsiniz.

2) Küçük/Orta Ölçekli VPS Üzerinde MySQL

Burada artık root yetkiniz var, disk şemanızı kontrol edebiliyorsunuz ve cron job’lar kurabilirsiniz. Tipik bir strateji şöyle olabilir:

• Birincil yöntem: Günlük tam Percona XtraBackup.
• Tamamlayıcı 1: Saatlik veya iki saatte bir binary log arşivleme ile PITR.
• Tamamlayıcı 2: günde birkaç kez LVM/ZFS snapshot (özellikle şema değişikliği veya büyük güncellemeler öncesi).
• Offsite: XtraBackup çıktılarını veya sıkıştırılmış snapshot imajlarını S3 uyumlu uzak depolamaya kopyalamak.

Bu seviyede genelde mysqldump’ı sadece şema değişikliği öncesi, belirli tablolar için veya “insan okunabilir” bir yedek gerektiğinde kullanıyoruz.

3) Büyük VPS/Dedicated ve Yüksek Trafikli Siteler

Örneğin DCHost üzerinde çalışan büyük bir WooCommerce mağazası, çok kiracılı SaaS, yoğun yazma trafiği alan bir mikroservis mimarisi… Bu durumda hedefler daha iddialı:

• RPO: 5–15 dakika.
• RTO: 15–60 dakika.

Bu tip ortamlarda tipik bir tasarım şöyle olur:

• Birincil yöntem: Saatlik XtraBackup incremental + gecelik tam XtraBackup.
• Binary log ile PITR: MySQL binary log’ları ayrı disk veya dizine alınır ve sık sık uzak depoya gönderilir.
• Snapshot katmanı: Kritik güncellemelerden önce disk snapshot alınır; bu sayede “1 adım geri” dönmek saniyeler alır.
• Offsite ve fidye yazılım koruması: XtraBackup çıktılarını S3 uyumlu depoya gönderip, Object Lock veya benzeri özelliklerle silinemez/sabit yedekler tutulur.

Bu tür yapılarda, yedekleme planı tek başına yeterli değildir; felaket kurtarma planının da yazılı ve test edilmiş olması gerekir. Aksi hâlde “Yedeğimiz var ama nasıl döneceğiz?” sorusu en kritik anda karşınıza çıkar.

Gerçekçi Bir Örnek: DCHost Üzerinde WooCommerce MySQL Yedekleme Tasarımı

Somut bir mimari üzerinden gidelim. Diyelim ki DCHost üzerinde NVMe diskli bir VPS’iniz var, üzerinde WooCommerce çalışıyor ve veritabanı 40 GB. Günlük sipariş sayınız yüzlerle, zaman zaman binlerle ifade ediliyor.

Bu senaryo için pratik bir MySQL yedekleme stratejisi şöyle olabilir:

• Gecelik 03:00 tam XtraBackup: /backups/mysql-full dizinine alınıyor, sıkıştırılıyor.
• Her saat incremental XtraBackup: Son tam yedeğe göre sadece değişen bloklar tutuluyor.
• Her 10 dakikada bir binary log senkronizasyonu: Binary log’lar ayrı bir klasöre dönüyor ve oradan S3 uyumlu uzak depoya kopyalanıyor.
• Her 4 saatte bir LVM snapshot: MySQL data volume’ü için kısa süreli uygulama-tutarlı snapshot alınıyor (fsfreeze + LVM snapshot).
• Offsite kopya: Gece alınan tam XtraBackup’lar 30 gün, incremental’lar 7 gün, binary log’lar 7–14 gün S3 üzerinde saklanıyor.

Böyle bir kurgu ile:

• “10 dakika önceki duruma dön” isteğini PITR ile karşılayabilirsiniz.
• “Bu sabahki şemayı test etmek istiyorum” dediğinizde, snapshot’tan hızlı bir test ortamı ayağa kaldırabilirsiniz.
• “Geçen hafta Perşembe günkü veri setine dön” isteğini, ilgili tam XtraBackup + incremental + binary log kombinasyonu ile çözebilirsiniz.

Tüm bunların çalıştığından emin olmanın tek yolu, düzenli geri dönüş testleri yapmaktır. Yani sadece yedek almak değil, yedekten gerçekten ayağa kalkabildiğinizi periyodik olarak doğrulamak gerekiyor.

mysqldump, XtraBackup ve Snapshot Arasında Seçim İçin Kontrol Listesi

Son olarak elinizde pratik bir karar aracı kalsın istiyorum. Aşağıdaki soruları yanıtlayarak hangi yöntemin öncelikli olması gerektiğini netleştirebilirsiniz.

Soru 1: Sunucuya Root Erişiminiz Var mı?

• Hayır, paylaşımlı hosting kullanıyorum: Panel yedekleri + mysqldump. Snapshot ve XtraBackup genelde mümkün değil.
• Evet, VPS/dedicated yönetiyorum: XtraBackup ve snapshot seçenekleri masaya gelir.

Soru 2: Veritabanı Boyutunuz Ne Kadar?

• < 5 GB: mysqldump + panel yedekleri çoğu senaryoda yeterli.
• 5–50 GB: mysqldump restore süresi uzamaya başlar; XtraBackup mantıklı hale gelir.
• > 50 GB: Mantıksal yedekleri sadece ek güvenlik veya belirli tablolar için kullanın; ana yöntem fiziksel yedek + snapshot olsun.

Soru 3: Kabul Edebilir Veri Kaybı (RPO) Ne?

• 24 saat ve üzeri: Günlük tam mysqldump veya XtraBackup yeterli.
• 1–4 saat: Günlük tam yedeğe ek olarak saatlik incremental (XtraBackup) önerilir.
• dakikalar mertebesi: Binary log arşivleme + sık incremental + snapshot kombinasyonu kaçınılmaz.

Soru 4: Kabul Edebilir Kesinti Süresi (RTO) Ne?

• Birkaç saat: mysqldump restore’ları tolere edilebilir.
• 30–60 dakika: XtraBackup restore + hazır bekleyen test ortamları gerekir.
• Dakikalar: Snapshot’tan hızlı dönüş + replikasyon veya yedek sunucu gibi ekstra mekanizmalar devreye girer.

Sonuç: MySQL Yedekleme, Araç Seçiminden Fazlası

mysqldump, Percona XtraBackup ve snapshot’lar tek başına “yedekleme stratejisi” değildir; sadece stratejinin parçalarıdır. Gerçek dünyada başarılı olan projelerin ortak noktası, bu araçları RPO/RTO hedefleriyle, 3-2-1 prensibiyle ve felaket kurtarma planlarıyla birlikte düşünmeleridir. Bir diğer ortak nokta da şudur: Hepsi düzenli olarak yedekten geri dönüş testi yapar, teoriyi pratikle doğrular.

DCHost olarak günlük operasyonlarda şunu çok net görüyoruz: Küçük bir blog için bile basit bir mysqldump + panel yedeği, kritik bir WooCommerce için ise XtraBackup + snapshot + offsite S3 kombinasyonu hayat kurtarıyor. Altyapınız paylaşımlı hosting, VPS, dedicated veya colocation olsun; MySQL veritabanınız için size özel bir yedekleme topolojisi kurmak mümkün.

Eğer “Bizim senaryoda hangisi birincil yöntem olmalı, hangisi yedek kalsın?” diye düşünüyorsanız, RPO/RTO hedeflerinizi kabaca netleştirip ekibimizle paylaşın; birlikte sizin için uygun mysqldump / XtraBackup / snapshot kombinasyonunu ve saklama sürelerini çıkaralım. DCHost üzerinde yeni bir VPS veya dedicated sunucu planlıyorsanız, kurulum aşamasında MySQL yedekleme mimarisini de baştan doğru kurgulamak, sonradan telafi etmekten çok daha kolay ve güvenli olacaktır.