MySQL ve MariaDB Yedekleme Stratejileri: Sunucularda Güvenli Veri Koruma Rehberi

MySQL ve MariaDB Yedekleme Stratejileri: Sunucularda Güvenli Veri Koruma Rehberi - Corelux
30 Eyl 2026
Paylaş:

MySQL ve MariaDB Yedekleme Stratejileri: Sunucularda Güvenli Veri Koruma Rehberi

Son Güncelleme: Eylül 2026

MySQL yedekleme ve MariaDB yedekleme süreçleri, web siteleri, e-ticaret projeleri, müşteri panelleri ve kurumsal uygulamalar için veri güvenliğinin temelini oluşturur. Bir veritabanı kaybı yalnızca teknik bir kesinti değil; siparişlerin, kullanıcı hesaplarının, içeriklerin ve finansal kayıtların kaybolması anlamına gelebilir. Bu rehberde veri kurtarma, otomatik yedekleme, güvenli saklama, test geri yükleme ve hosting ortamlarında doğru yedekleme planı oluşturma konularını pratik örneklerle ele alacağız.

İçindekiler

MySQL ve MariaDB Yedekleme Nedir?

MySQL ve MariaDB yedekleme, veritabanındaki tabloların, kayıtların, indekslerin, kullanıcı yetkilerinin ve gerektiğinde ikili günlüklerin düzenli aralıklarla kopyalanması işlemidir. Amaç, donanım arızası, yanlış sorgu, siber saldırı, yazılım hatası, dosya sistemi bozulması veya insan hatası gibi durumlarda veriyi kabul edilebilir bir süre içinde geri getirebilmektir.

Yedekleme yalnızca .sql dosyası üretmekten ibaret değildir. İyi bir yedekleme stratejisi; neyin yedekleneceğini, ne sıklıkla yedekleneceğini, yedeklerin nerede saklanacağını, kaç gün korunacağını, kimin erişeceğini ve nasıl geri yükleneceğini belirleyen bütüncül bir güvenlik planıdır. Özellikle WordPress, Laravel, e-ticaret, CRM ve muhasebe uygulamalarında veritabanı, uygulamanın en kritik bileşenidir.

Birçok işletme yedek aldığını düşünür; ancak gerçek bir felaket anında yedeğin eksik, bozuk, eski veya geri yüklenemez olduğunu fark eder. Bu nedenle yedekleme başarısı, yalnızca yedek dosyasının oluşmasıyla değil, düzenli geri yükleme testleriyle doğrulanmalıdır.

Yedekleme Türleri ve Kullanım Senaryoları

Veritabanı yedekleme türleri, sistemin boyutuna, trafik yoğunluğuna, kurtarma hedeflerine ve sunucu mimarisine göre değişir. Küçük bir kurumsal web sitesi için günlük mysqldump yeterli olabilirken, yüksek trafikli bir e-ticaret platformunda tam yedek, artımlı yedek ve binlog tabanlı noktasal kurtarma birlikte kullanılmalıdır.

Yedekleme Türü Açıklama Avantaj Uygun Senaryo
Tam yedek Tüm veritabanının tek seferde kopyalanmasıdır. Geri yükleme süreci daha anlaşılırdır. Küçük ve orta ölçekli web siteleri
Artımlı yedek Son yedekten sonra değişen verilerin alınmasıdır. Disk alanı ve aktarım süresi tasarrufu sağlar. Büyük veritabanları
Mantıksal yedek SQL komutları olarak dışa aktarma işlemidir. Taşınabilir ve okunabilir yapı sunar. Geçiş, test ortamı, küçük projeler
Fiziksel yedek Veritabanı dosyalarının blok veya dosya düzeyinde kopyalanmasıdır. Büyük verilerde daha hızlı olabilir. Yoğun işlem gören sistemler
Noktasal kurtarma Belirli bir tarih ve saate geri dönebilme yöntemidir. Yanlış sorgu veya silme işlemlerinde etkilidir. E-ticaret ve finansal uygulamalar

Tam Yedekleme

Tam yedekleme, veritabanının belirli bir andaki eksiksiz kopyasını oluşturur. Yönetimi kolaydır; ancak büyük veritabanlarında zaman ve disk maliyeti artabilir. Özellikle günlük veya haftalık rutinlerde, tam yedekleme temel başlangıç noktasıdır.

Artımlı ve Fark Yedekleme

Artımlı yedekleme, yalnızca değişen verileri sakladığı için kaynak tüketimini azaltır. Fark yedekleme ise son tam yedekten bu yana oluşan değişiklikleri içerir. Bu yöntemlerde geri dönüş adımları daha karmaşık olabilir; çünkü tam yedekle birlikte ilgili artımlı zincirin de sağlıklı olması gerekir.

Mantıksal ve Fiziksel Yedekleme

Mantıksal yedekler genellikle mysqldump veya benzer araçlarla SQL formatında alınır. Fiziksel yedekler ise veri dosyalarının kopyalanmasıyla oluşturulur. Mantıksal yedekler sürümler arası taşımada esneklik sağlarken, fiziksel yedekler büyük veri kümelerinde daha hızlı geri dönüş avantajı sunabilir.

Yedekleme Planı Nasıl Oluşturulur?

Başarılı bir yedekleme planı oluşturmak için öncelikle uygulamanın iş değeri ve veri değişim hızı analiz edilmelidir. Bir blog sitesinde günde birkaç içerik değişirken, e-ticaret sitesinde dakikalar içinde sipariş, stok, sepet ve ödeme kayıtları oluşur. Bu iki sistemin aynı yedekleme politikasıyla korunması doğru değildir.

Planlama aşamasında iki önemli metrik kullanılır: RPO ve RTO. RPO yani Kurtarma Noktası Hedefi, ne kadar veri kaybının kabul edilebilir olduğunu belirtir. RTO yani Kurtarma Süresi Hedefi ise sistemin ne kadar sürede tekrar çalışır hale gelmesi gerektiğini tanımlar.

  • RPO düşükse: Yedekleme sıklığı artırılmalı, binlog veya replikasyon gibi yöntemler değerlendirilmelidir.
  • RTO düşükse: Geri yükleme prosedürü önceden test edilmeli, yedekler hızlı erişilebilir konumda tutulmalıdır.
  • Veri hacmi büyükse: Sıkıştırma, artımlı yedekleme ve ayrı depolama alanları kullanılmalıdır.
  • Uyumluluk gerekiyorsa: Saklama süresi, erişim kayıtları ve şifreleme politikaları dokümante edilmelidir.

Örnek bir küçük işletme web sitesinde günlük tam yedek, haftalık arşiv ve aylık harici kopya yeterli olabilir. Buna karşılık yoğun sipariş alan bir mağazada saatlik yedek, binlog saklama ve ayrı lokasyonda yedek depolama tercih edilmelidir.

mysqldump ile Mantıksal Yedekleme

mysqldump, MySQL ve MariaDB veritabanlarını SQL dosyası olarak dışa aktarmak için en yaygın kullanılan araçlardan biridir. Basit, taşınabilir ve birçok hosting ortamında erişilebilir olması nedeniyle özellikle küçük ve orta ölçekli projelerde tercih edilir.

Tek bir veritabanını yedeklemek için aşağıdaki komut kullanılabilir:

mysqldump -u kullanici_adi -p veritabani_adi > veritabani_adi.sql

Yedek dosyasını sıkıştırmak için gzip ile birlikte çalıştırabilirsiniz:

mysqldump -u kullanici_adi -p veritabani_adi | gzip > veritabani_adi_$(date +%F).sql.gz

Tüm veritabanlarını yedeklemek için --all-databases parametresi kullanılabilir:

mysqldump -u root -p --all-databases --single-transaction --routines --triggers --events | gzip > tum_veritabanlari_$(date +%F).sql.gz

Burada --single-transaction parametresi, InnoDB tablolarında tutarlı bir anlık görüntü alınmasına yardımcı olur. --routines, saklı yordamları; --triggers, tetikleyicileri; --events ise zamanlanmış veritabanı olaylarını dahil etmek için kullanılır. Bu parametreler atlanırsa uygulamanın bazı iş mantığı bileşenleri yedek dışında kalabilir.

Geri Yükleme Örneği

SQL dosyasını geri yüklemek için hedef veritabanı önceden oluşturulmalı ve ardından içe aktarma yapılmalıdır:

mysql -u kullanici_adi -p veritabani_adi < veritabani_adi.sql

Sıkıştırılmış yedeklerde işlem şu şekilde yapılabilir:

gunzip < veritabani_adi_2026-09-22.sql.gz | mysql -u kullanici_adi -p veritabani_adi

Geri yükleme işleminden önce üretim ortamında çalışan uygulamanın bakım moduna alınması, veri çakışmalarını ve kısmi yazma sorunlarını azaltır.

Fiziksel Yedekleme ve Büyük Veritabanları

Veritabanı boyutu büyüdükçe mysqldump işlemleri daha uzun sürebilir ve geri yükleme süresi uzayabilir. Büyük veri kümelerinde fiziksel yedekleme yöntemleri, veri dosyalarını doğrudan kopyalayarak daha hızlı sonuç verebilir. Ancak bu yöntemlerde veritabanı motoru, dosya tutarlılığı ve servis durumu daha dikkatli yönetilmelidir.

Fiziksel yedekleme özellikle yüksek trafikli uygulamalarda, büyük InnoDB tablolarında ve çok sayıda veritabanı barındıran sunucularda tercih edilir. Bu yöntemde dosya sistemi snapshot (anlık görüntü), LVM snapshot veya özel yedekleme araçları kullanılabilir. Fiziksel yedeklerin aynı veya uyumlu veritabanı sürümünde geri yüklenmesi çoğu zaman daha güvenlidir.

  • Avantaj: Büyük veritabanlarında daha hızlı yedek alma ve geri yükleme sağlayabilir.
  • Dezavantaj: Yanlış uygulanırsa tutarsız dosyalar üretme riski vardır.
  • Dikkat edilmesi gereken nokta: Yedek sırasında veri yazma işlemleri, log dosyaları ve tablo motoru davranışı hesaba katılmalıdır.

Eğer fiziksel yedekleme kullanılıyorsa, test sunucusunda düzenli geri yükleme yapılmalı ve servis başlangıç logları kontrol edilmelidir. Geri yüklenebilen yedek, yalnızca kopyalanmış dosyadan daha değerlidir.

Cron ile Otomatik Yedekleme

Manuel yedekleme, unutulma ihtimali nedeniyle sürdürülebilir bir yöntem değildir. Linux sunucularda cron kullanılarak günlük, saatlik veya haftalık yedekleme görevleri otomatik hale getirilebilir. Otomasyon, sistem yöneticisinin iş yükünü azaltırken yedekleme disiplinini de güçlendirir.

Aşağıdaki örnek script, belirlenen veritabanını yedekler, sıkıştırır ve eski yedekleri temizler:

#!/bin/bash
BACKUP_DIR="/var/backups/mysql"
DB_NAME="uygulama_db"
DB_USER="backup_user"
DATE=$(date +%F_%H-%M)
RETENTION_DAYS=14

mkdir -p "$BACKUP_DIR"
mysqldump -u "$DB_USER" -p'SIFREYI_BURAYA_YAZMAYIN' --single-transaction --routines --triggers --events "$DB_NAME" | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz"
find "$BACKUP_DIR" -type f -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

Bu örnek öğretici amaçlıdır. Gerçek sistemlerde parolayı doğrudan script içine yazmak yerine ~/.my.cnf dosyası, güvenli değişken yönetimi veya yedekleme kullanıcısına özel sınırlı yetkilendirme tercih edilmelidir.

Cron görevi eklemek için:

crontab -e

Her gece saat 03:30’da çalışacak örnek görev:

30 3 * * * /usr/local/bin/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1

Otomatik yedekleme sonrasında log dosyalarının kontrol edilmesi gerekir. Dosya oluşmuş olsa bile yedek boş, eksik veya hata mesajı içeren bir çıktı olabilir. Bu nedenle dosya boyutu, çıkış kodu ve örnek geri yükleme testleri izlenmelidir.

Yedekleri Güvenli Saklama ve Şifreleme

Yedek dosyaları, canlı veritabanı kadar hassas bilgiler içerir. Kullanıcı e-postaları, parola özetleri, müşteri adresleri, sipariş kayıtları ve özel uygulama verileri yedek içinde bulunabilir. Bu nedenle yedeklerin güvenliği, veritabanı güvenliğinin ayrılmaz parçasıdır.

  • Ayrı lokasyon: Yedekler yalnızca aynı sunucuda tutulmamalı, farklı bir fiziksel veya mantıksal alana kopyalanmalıdır.
  • Şifreleme: Hassas yedekler aktarım ve depolama sırasında şifrelenmelidir.
  • Erişim kontrolü: Yedek dizinlerine yalnızca yetkili kullanıcılar erişebilmelidir.
  • Saklama politikası: Günlük, haftalık ve aylık yedeklerin ne kadar korunacağı net olmalıdır.
  • Aktarım güvenliği: Yedekler uzak sunucuya gönderiliyorsa güvenli protokoller kullanılmalıdır.

Basit bir şifreleme örneği için gpg kullanılabilir:

gpg -c veritabani_adi_2026-09-22.sql.gz

Bu komut, simetrik şifreleme ile korunan bir dosya oluşturur. Kurumsal ortamlarda anahtar yönetimi, erişim yetkileri ve anahtar yedekleme süreçleri ayrıca planlanmalıdır. Şifrelenmiş yedeğin parolası kaybolursa yedek pratikte kullanılamaz hale gelir.

Corelux üzerinde barındırılan projelerde düzenli yedekleme ihtiyacı olan işletmeler, ek güvenlik katmanı için Yedekleme Hizmeti seçeneklerini değerlendirebilir. Veritabanı yedekleri, uygulama dosyaları ve yapılandırma dosyaları birlikte ele alındığında felaket kurtarma süreci daha yönetilebilir hale gelir.

Geri Yükleme Testleri ve Felaket Kurtarma

Yedekleme stratejisinin en kritik kısmı geri yükleme testidir. Bir yedeğin var olması, o yedeğin çalıştığı anlamına gelmez. Dosya bozuk olabilir, eksik tablo içerebilir, karakter seti sorunları oluşabilir veya hedef sunucuda uyumsuz sürüm bulunabilir.

Test geri yükleme için üretim verilerini doğrudan canlı sisteme yazmak yerine ayrı bir test veritabanı kullanılmalıdır:

mysql -u test_user -p test_db < veritabani_adi.sql

Geri yükleme sonrasında aşağıdaki kontroller yapılmalıdır:

  • Tablo sayısı: Kaynak ve hedef veritabanındaki tablo sayısı karşılaştırılmalıdır.
  • Kayıt sayıları: Kritik tablolarda satır sayısı kontrol edilmelidir.
  • Karakter seti: Türkçe karakterlerin bozulmadığı doğrulanmalıdır.
  • Uygulama testi: Giriş, sipariş, içerik görüntüleme ve yönetim paneli gibi işlevler denenmelidir.
  • Performans: Büyük veri geri yüklemelerinde indeksler ve sorgu süreleri gözlemlenmelidir.

Felaket kurtarma planı, yalnızca teknik komutlardan oluşmamalıdır. Kimin hangi adımı uygulayacağı, müşteriye nasıl bilgi verileceği, DNS veya uygulama yönlendirmelerinin nasıl yapılacağı ve hangi yedeğin kullanılacağı önceden belirlenmelidir. Kritik sistemlerde bu plan belirli aralıklarla tatbikat şeklinde test edilmelidir.

Hosting, VPS ve VDS Ortamlarında Strateji

Yedekleme yaklaşımı, kullanılan altyapıya göre değişir. Paylaşımlı hosting ortamında kullanıcı genellikle panel üzerinden veritabanı dışa aktarma veya otomatik yedekleme seçeneklerine erişir. VPS ve VDS sunucularda ise kullanıcı daha fazla kontrol sahibidir; ancak sorumluluk da artar.

Ortam Kontrol Seviyesi Önerilen Yaklaşım
Paylaşımlı hosting Sınırlı Panel yedekleri, manuel dışa aktarma, düzenli indirme
VPS Orta-yüksek Cron tabanlı mysqldump, uzak kopya, şifreleme
VDS Yüksek Tam sistem planı, snapshot, veritabanı yedeği, izleme
Kiralık sunucu Çok yüksek Özel yedekleme mimarisi, ayrı disk, harici depolama, felaket kurtarma

Küçük ve orta ölçekli siteler için Linux Hosting çözümleri, veritabanı yönetimini kolaylaştıran pratik bir başlangıç sunabilir. Daha fazla kontrol, özel kaynak ve otomasyon isteyen projelerde Sanal Sunucu seçenekleri değerlendirilebilir. Veritabanı yükü yüksek, trafik dalgalanmaları yoğun veya özel güvenlik gereksinimleri bulunan işletmeler için Kiralık Sunucu altyapısı daha esnek bir zemin sağlar.

Önemli nokta, altyapı türü ne olursa olsun veritabanı yedeğinin uygulama dosyaları, medya dosyaları, yapılandırma dosyaları ve SSL bileşenleriyle birlikte düşünülmesidir. Yalnızca veritabanını geri getirmek çoğu zaman uygulamayı tamamen ayağa kaldırmak için yeterli değildir.

En İyi Uygulamalar ve Kontrol Listesi

MySQL ve MariaDB yedekleme süreçlerinde süreklilik sağlamak için standart bir kontrol listesi oluşturmak faydalıdır. Bu liste, yeni sunucu kurulumlarında, müşteri projelerinde ve bakım çalışmalarında tekrar tekrar kullanılabilir.

  1. Yedekleme kapsamını belirleyin: Hangi veritabanları, kullanıcı yetkileri, rutinler ve olaylar yedeklenecek netleştirin.
  2. Uygun zamanı seçin: Yedekleri trafiğin düşük olduğu saatlerde çalıştırın.
  3. Yetkileri sınırlayın: Yedekleme kullanıcısına yalnızca gerekli izinleri verin.
  4. Sıkıştırma kullanın: Büyük SQL dosyalarında disk alanı ve aktarım süresinden tasarruf edin.
  5. Şifreleme uygulayın: Hassas veritabanı yedeklerini şifresiz saklamayın.
  6. Uzak kopya oluşturun: Aynı sunucuda kalan yedek, disk arızasında kaybolabilir.
  7. Geri yükleme testi yapın: En az aylık olarak test ortamına yedek dönün.
  8. Logları izleyin: Başarısız yedekleme denemelerini erken fark edin.
  9. Saklama politikasını yönetin: Eski yedeklerin kontrolsüz büyümesini engelleyin.
  10. Dokümantasyon hazırlayın: Acil durumda uygulanacak adımları yazılı hale getirin.

Bu kontrol listesi, tek seferlik bir görev değil, düzenli bakım kültürünün parçası olarak görülmelidir. Sunucu büyüdükçe yedekleme süresi, disk kullanımı, ağ aktarımı ve geri yükleme hızı yeniden değerlendirilmelidir.

Sıkça Sorulan Sorular

MySQL yedeği ne sıklıkla alınmalıdır?

Yedekleme sıklığı veri değişim hızına bağlıdır. Kurumsal tanıtım sitelerinde günlük yedek yeterli olabilirken, e-ticaret ve üyelik sistemlerinde saatlik yedekleme veya binlog tabanlı noktasal kurtarma gerekebilir.

mysqldump büyük veritabanları için uygun mudur?

Küçük ve orta ölçekli veritabanlarında oldukça kullanışlıdır. Ancak çok büyük veritabanlarında yedek alma ve geri yükleme süreleri uzayabilir. Bu durumda fiziksel yedekleme, snapshot veya artımlı yedekleme stratejileri değerlendirilmelidir.

Yedeği aynı sunucuda tutmak yeterli mi?

Hayır. Aynı sunucuda tutulan yedek, disk arızası, fidye yazılımı veya yanlış silme durumunda kaybolabilir. En az bir kopyanın farklı bir lokasyonda veya güvenli harici depolama alanında saklanması önerilir.

Veritabanı yedekleri şifrelenmeli mi?

Evet. Veritabanı yedekleri çoğu zaman canlı sistemdeki tüm hassas bilgileri içerir. Özellikle müşteri verisi, kişisel veri veya ödeme süreciyle ilişkili kayıtlar varsa yedeklerin şifrelenmesi güvenlik açısından önemlidir.

Yedek başarılı görünüyorsa geri yükleme testi yine de gerekli mi?

Evet. Dosyanın oluşması, içeriğin eksiksiz ve geri yüklenebilir olduğu anlamına gelmez. Düzenli test geri yükleme, bozuk dosya, eksik tablo, karakter seti hatası veya sürüm uyumsuzluğu gibi problemleri önceden ortaya çıkarır.

WordPress siteleri için yalnızca veritabanı yedeği yeterli olur mu?

Genellikle hayır. WordPress veritabanı içerik, ayar ve kullanıcı bilgilerini saklar; ancak tema, eklenti ve medya dosyaları dosya sistemindedir. Tam kurtarma için veritabanı ile birlikte uygulama dosyalarının da yedeklenmesi gerekir.

Yedekleme kullanıcısına root yetkisi vermek doğru mu?

Güvenlik açısından mümkün olduğunca sınırlı yetkili bir kullanıcı oluşturulmalıdır. Root yetkisi, yedekleme aracının ele geçirilmesi durumunda tüm veritabanı sunucusunun riske girmesine neden olabilir.

Sonuç

MySQL ve MariaDB yedekleme stratejisi, her web projesi için kritik bir güvenlik ve süreklilik unsurudur. Doğru yapılandırılmış bir plan; düzenli yedek alma, güvenli saklama, şifreleme, uzak kopya, saklama politikası ve test geri yükleme adımlarını birlikte içermelidir. Yedekleme yalnızca olası felaketlere karşı değil, hatalı güncelleme, yanlış sorgu, kullanıcı hatası ve siber saldırı gibi günlük risklere karşı da koruma sağlar.

Corelux altyapısında projenizin gereksinimlerine göre Hosting, Türkiye VDS Sunucu, Bulut Sunucu ve Yedekleme Hizmeti seçeneklerini değerlendirerek veritabanı güvenliğinizi daha planlı hale getirebilirsiniz. Unutmayın: En iyi yedek, yalnızca alınmış olan değil; düzenli test edilmiş, güvenli saklanmış ve ihtiyaç anında hızla geri yüklenebilen yedektir.

Yazar

Boran BAR

Chat on WhatsApp