Veritabanı Yedekleme ve Geri Yükleme (mysqldump)

Bir veritabanı çökebilir, yanlış bir komutla veriler silinebilir veya sunucu arızalanabilir. Bu yüzden düzenli veritabanı yedeklemesi, her ciddi projenin olmazsa olmazıdır. MySQL ve MariaDB için en yaygın yedekleme aracı mysqldump‘tir; veritabanınızı yeniden oluşturabilecek SQL komutları içeren tek bir dosya üretir. Bu rehberde mysqldump ile yedek alma, geri yükleme, otomatik yedekleme ve büyük veritabanları için alternatifleri adım adım anlatıyoruz.

Yedeklerinizi güvenli biçimde saklamak ve gerektiğinde hızla geri yüklemek için yeterli disk alanı ve dengeli IO sunan bir VPS/sunucu önemlidir.

mysqldump Nedir?

mysqldump, “mantıksal yedekleme” yapan bir araçtır: veritabanını yeniden üretecek CREATE ve INSERT SQL ifadelerini düz metin bir dosyaya yazar. Bu dosya taşınabilir, insan tarafından okunabilir ve farklı bir sunucuya, hatta farklı bir MySQL/MariaDB sürümüne kolayca geri yüklenebilir. Küçük-orta boyutlu veritabanları için ideal, basit ve güvenilir bir yöntemdir.

Mantıksal yedeklemenin karşıtı fiziksel yedeklemedir (örneğin Percona XtraBackup veya MariaDB için mariabackup). Fiziksel yedekler veri dosyalarını doğrudan kopyalar; çok büyük veritabanlarında daha hızlıdır ama taşınabilirliği düşüktür ve genelde aynı sürüm/yapılandırmaya geri yüklenir. Çoğu web projesi için mysqldump’ın sunduğu esneklik fazlasıyla yeterlidir.

Önemli: mysqldump mi, mariadb-dump mi?

Son yıllarda iki kritik değişiklik yaşandı; modern bir sunucuda çalışırken bunları bilmek hata almanızı önler:

• MariaDB 11.0 ve sonrası: Komut artık resmi olarak mariadb-dump adını taşır. Eski mysqldump ismi hala bir symlink olarak çalışır, ancak ileride kaldırılabilir. Yeni kurulumlarda mariadb-dump kullanmanız daha güvenlidir.
• MySQL 8.4 ve sonrası: Bir dönem paralel yedekleme için önerilen mysqlpump aracı tamamen kaldırıldı. Artık MySQL tarafında resmi alternatifler mysqldump ile birlikte MySQL Shell dump araçlarıdır.

Pratikte komutların sözdizimi aynı kaldığı için bu rehberdeki tüm örnekler hem mysqldump hem de mariadb-dump ile birebir çalışır. Sadece komut adını değiştirmeniz yeterlidir.

Yedek Alma ve Geri Yükleme

En temel kullanım şu şekildedir. Parolayı -p bayrağından sonra boş bırakırsanız terminal güvenli bir şekilde sorar:

# Tek veritabani yedekle
mysqldump -u root -p db_adi > yedek.sql

# Geri yukle (db onceden olusturulmus olmali)
mysql -u root -p db_adi < yedek.sql

# Birden fazla belirli db (CREATE DATABASE iceren yedek)
mysqldump -u root -p --databases db1 db2 > yedek.sql

# Tum sunucuyu yedekle
mysqldump -u root -p --all-databases > tum_sunucu.sql

Önemli ayrım: --databases veya --all-databases kullandığınızda yedek dosyası CREATE DATABASE ifadeleri içerir ve veritabanlarını kendi oluşturur. Tek veritabanı adıyla aldığınız yedekte (parametresiz) bu ifade bulunmaz; geri yüklemeden önce veritabanını elle oluşturmanız gerekir.

Önerilen Tam Yedek Komutu

InnoDB tabloları için, siteyi durdurmadan tutarlı bir yedek almak üzere şu komut önerilir:

mysqldump -u root -p --single-transaction --routines --triggers --events db_adi > yedek.sql

Bayrakların ne yaptığını bilelim:

• --single-transaction: Tabloları kilitlemeden, tutarlı bir anlık görüntü (snapshot) alır. Yalnızca InnoDB motoru için tutarlılık garantisi verir; MyISAM tabloları bu sırada değişebilir.
• --routines: Saklı yordamları (stored procedure) ve fonksiyonları dahil eder.
• --triggers: Tetikleyicileri dahil eder (varsayılan olarak zaten dahil edilir, ama açıkça belirtmek iyi alışkanlıktır).
• --events: Zamanlanmış olayları (event scheduler) dahil eder.

Çoğu modern web uygulamasında (WordPress, Laravel, Magento vb.) tablolar InnoDB olduğundan, bu komut canlı ortamda gönül rahatlığıyla kullanılabilir.

Yedeği Sıkıştırma

SQL dosyaları düz metin olduğu için çok yer kaplar. Yedeği anında sıkıştırarak hem disk hem yedekleme süresinden tasarruf edebilirsiniz:

# gzip ile sikistirilmis yedek
mysqldump -u root -p --single-transaction db_adi | gzip > yedek.sql.gz

# Sikistirilmis yedegi geri yukle
gunzip < yedek.sql.gz | mysql -u root -p db_adi

Tipik bir veritabanında gzip, dosya boyutunu yüzde 70-85 oranında küçültür. Çok çekirdekli sunucularda pigz kullanarak sıkıştırmayı paralel hale getirip süreyi belirgin şekilde düşürebilirsiniz.

Otomatik (Cron) Yedekleme

Her gün otomatik, tarih damgalı yedek almak için bir cron görevi ekleyin:

# Her gece 01:00'de sikistirilmis, tarihli yedek
0 1 * * * mysqldump -u root --single-transaction db_adi | gzip > /var/backups/db_$(date +%Y-%m-%d).sql.gz

# 14 gunden eski yedekleri otomatik sil
30 1 * * * find /var/backups -name "db_*.sql.gz" -mtime +14 -delete

Cron’da % karakteri özel anlam taşıdığı için % şeklinde kaçırılmalıdır; aksi halde görev çalışmaz. Ayrıca parolayı komut satırında açık yazmak güvenlik açığıdır. Bunun yerine ev dizininizdeki ~/.my.cnf dosyasını kullanın:

# ~/.my.cnf (izinler 600 olmali: chmod 600 ~/.my.cnf)
[mysqldump]
user=root
password=GIZLI_PAROLA

Bu dosya mevcutken komutlarda parola belirtmenize gerek kalmaz. --login-path (mysql_config_editor ile) daha da güvenli, şifrelenmiş bir alternatiftir.

GTID ve Replikasyon Notu

Sunucunuzda GTID açık (gtid_mode=ON) ise dikkatli olun: sistem tablolarını içeren bir yedeği yüklemek hata verebilir, çünkü bazı sistem tabloları işlemsel olmayan MyISAM motorunu kullanır ve bu kombinasyon GTID ile izin verilmez. Bu durumda --set-gtid-purged=OFF bayrağını değerlendirin veya sistem veritabanlarını (mysql, sys) yedek dışında bırakın. Standart bir uygulama veritabanını yedekleyip geri yüklerken çoğunlukla bu sorunla karşılaşmazsınız.

Büyük Veritabanları: Ne Zaman Alternatif Aramalı?

mysqldump tek iş parçacıklı (single-threaded) çalışır. Yedek alma adımı kabul edilebilir sürede bitse bile, geri yükleme tek tek INSERT ifadelerini, indeks oluşturmalarını ve disk IO işlemlerini sırayla yaptığından çok yavaşlayabilir. Pratik kural: veritabanınız 10 GB eşiğini aştığında paralel araçlara bakmanın zamanı gelmiştir. Aşağıdaki tablo seçimi kolaylaştırır:

Ölçek karşılaştırması için somut bir örnek: bağımsız testlerde 10 GB’lik bir veritabanının yedeği mysqldump ile yaklaşık 20 dakika sürerken, MySQL Shell paralel dump aracı aynı işi 1,5 dakikada bitirebiliyor; geri yükleme tarafında da fark 16 dakikaya karşı 4 dakika seviyesinde. Yani veriniz büyüdükçe paralel araçlara geçmek sadece konfor değil, kurtarma süresi (RTO) açısından zorunluluk haline gelir.

Sağlam Bir Yedekleme Stratejisi: 3-2-1 Kuralı

Tek bir yedek dosyası sahip olduğunuz yedek değildir; aynı diskte duran yedek, disk arızasında veriyle birlikte yok olur. Sektörde kabul gören 3-2-1 kuralı şunu der:

• 3 kopya verinizi tutun (1 canlı + 2 yedek).
• 2 farklı ortamda saklayın (örneğin yerel disk + bulut/uzak sunucu).
• 1 kopya mutlaka fiziksel olarak başka bir konumda (off-site) olsun.

Pratikte bu, günlük yerel cron yedeğinizi ek olarak uzak bir sunucuya veya nesne depolama alanına (rsync/rclone/S3 uyumlu) göndermek anlamına gelir. Alastyr’da barındırılan hesaplarda günlük otomatik yedekleme standart olarak sunulur; yine de kritik veriniz için bağımsız, sizin kontrolünüzdeki bir yedek kopya tutmanız en sağlıklı yaklaşımdır.

Yedek Test Edilmemişse Yedek Sayılmaz

En sık yapılan hata, yedeklerin yıllarca alınıp hiç test edilmemesidir. Bozuk veya eksik bir yedeği ancak felaket anında fark etmek, en kötü senaryodur. Ayda en az bir kez yedeğinizi boş bir test veritabanına geri yükleyin ve veri bütünlüğünü kontrol edin:

# Test geri yukleme dogrulamasi
mysql -u root -p -e "CREATE DATABASE test_geri_yukleme;"
gunzip < yedek.sql.gz | mysql -u root -p test_geri_yukleme
mysql -u root -p -e "SHOW TABLES;" test_geri_yukleme

Dikkat Edilmesi Gerekenler

• Tek veritabanı yedeği (--databases olmadan) CREATE DATABASE içermez; geri yüklemeden önce veritabanını oluşturun.
• --single-transaction ile --lock-tables birlikte kullanılamaz; biri diğerini devre dışı bırakır.
• --single-transaction yalnızca InnoDB için tutarlılık garantisi verir. MyISAM tablolarınız varsa, yedek sırasında DDL (ALTER TABLE vb.) çalıştırmaktan kaçının.
• Yedek dosyasının karakter setini koruyun; --default-character-set=utf8mb4 ile Türkçe karakter sorunlarının önüne geçin.
• Yedekleri mutlaka başka bir konumda (farklı disk/sunucu/bulut) da saklayın ve düzenli olarak test edin.

Sıkça Sorulan Sorular

mysqldump MariaDB’de çalışır mı?

Evet. mysqldump MariaDB ile tam uyumludur. MariaDB 11.0 ve sonrasında komutun resmi adı mariadb-dump olmuştur; mysqldump ise symlink olarak çalışmaya devam eder. Komut sözdizimi aynı olduğundan örnekleri her iki isimle de kullanabilirsiniz.

–single-transaction ne işe yarar?

Tabloları kilitlemeden, belirli bir andaki tutarlı görüntüyü yedekler. Böylece canlı site yedekleme sırasında kesintisiz çalışmaya devam eder. Bu tutarlılık garantisi yalnızca InnoDB motoru için geçerlidir.

Tek veritabanı yedeğini geri yüklerken hata alıyorum, neden?

Genellikle hedef veritabanı henüz oluşturulmamıştır. Parametresiz alınan yedek CREATE DATABASE içermez; önce veritabanını oluşturun, sonra geri yükleyin. Ayrıca geri yükleyen kullanıcının yeterli yetkiye sahip olduğundan emin olun.

Büyük veritabanları için mysqldump uygun mu?

10 GB altındaki veritabanları için gayet uygundur. Daha büyük veritabanlarında tek iş parçacıklı olması nedeniyle yedek ve özellikle geri yükleme yavaşlar. Bu durumda MySQL Shell dump araçları, mydumper veya fiziksel yedek (mariabackup/XtraBackup) tercih edilir.

Parolayı komut satırında yazmadan nasıl yedek alırım?

~/.my.cnf dosyasında kullanıcı ve parolayı tanımlayıp dosya iznini 600 yapın, ya da mysql_config_editor ile şifrelenmiş bir –login-path oluşturun. Böylece cron görevlerinde bile parola açıkta kalmaz.

Yedeği nasıl sıkıştırırım?

mysqldump çıktısını bir pipe ile gzip veya pigz’e göndererek anında sıkıştırabilirsiniz. Geri yüklerken gunzip ile açıp doğrudan mysql’e aktarırsınız. Sıkıştırma, disk kullanımını yüzde 70-85 azaltır.

Cron yedeğinde tarih damgası neden bozuk geliyor?

Cron, % karakterini özel olarak yorumlar. date komutundaki yüzde işaretlerini % şeklinde kaçırmanız gerekir. Aksi halde görev ya hata verir ya da dosya adı yanlış oluşur.

Yedek ne sıklıkla alınmalı?

Veri değişim hızına bağlıdır. Günlük işlem gören bir e-ticaret veya üyelik sitesinde günlük, hatta saatlik yedek mantıklıdır. Nadiren güncellenen bir kurumsal sitede günlük yedek çoğu durumda yeterlidir. Kritik sistemlerde ek olarak binlog tabanlı noktasal kurtarma (point-in-time recovery) düşünülmelidir.

Yedeğinin gerçekten çalıştığını nasıl bilirim?

Yedeğinizi ara ara boş bir test veritabanına geri yükleyip tablo sayısını ve veri bütünlüğünü kontrol edin. Test edilmemiş bir yedek, ihtiyaç anında çalışmadığında en büyük hayal kırıklığını yaratır.