mysqldump ile Veritabanı Yedekleme

Bir web sitesinin ya da uygulamanın kalbi neredeyse her zaman veritabanıdır. Dosyalarınızı yeniden yükleyebilir, sunucuyu baştan kurabilirsiniz; ama siparişler, kullanıcılar, yazılar ve ayarlar bir kez kaybolduğunda geri getirmenin yolu yoktur. İşte bu yüzden veritabanı yedeği, bir sistem yöneticisinin gece rahat uyumasını sağlayan en temel alışkanlıktır. MySQL ve MariaDB dünyasında bu işin standart aracı ise mysqldump'tır: neredeyse her sunucuda hazır gelir, tek satırlık bir komutla çalışır ve ürettiği çıktı düz metin bir SQL dosyasıdır. Yani yedeğinizi bir editörle açıp içine bakabilir, farklı bir sunucuya taşıyabilir, hatta gerektiğinde tek bir tabloyu elle geri alabilirsiniz.

Bu rehberde mysqldump'ı gerçek bir üretim ortamında nasıl kullandığımızı adım adım anlatacağız. Tek bir veritabanını da tüm sunucuyu da nasıl yedekleyeceğinizi, --single-transaction ile siteyi kilitlemeden tutarlı yedek almayı, gzip ile dosya boyutunu düşürmeyi, yalnızca şema ya da yalnızca veri almayı, yedeği geri yüklemeyi ve son olarak cron ile tarih damgalı otomatik yedekleri kurup bunları başka bir sunucuya taşımayı göreceksiniz. Komutları olduğu gibi kopyalayıp kullanabilir, kendi ortamınıza göre uyarlayabilirsiniz.

mysqldump Nedir ve Ne Zaman Kullanılır#

mysqldump, MySQL/MariaDB veritabanınızın içeriğini bir dizi SQL komutuna dönüştüren komut satırı aracıdır. Ürettiği dosya, tabloları yeniden oluşturacak CREATE TABLE ifadelerini ve satırları yerine koyacak INSERT ifadelerini içerir. Bu tür yedeğe "mantıksal yedek" (logical backup) denir; çünkü veriyi ham disk bloğu olarak değil, anlamlı SQL komutları olarak saklar. Bunun karşısında bir de veri dosyalarını olduğu gibi kopyalayan "fiziksel yedek" (Percona XtraBackup gibi) yaklaşımı vardır.

Mantıksal yedeğin en büyük avantajı taşınabilirlik ve okunabilirliktir. Bir mysqldump çıktısını MySQL 5.7'den MariaDB 10.6'ya, paylaşımlı hostingten kendi sunucunuza sorunsuz taşıyabilirsiniz. Dezavantajı ise çok büyük veritabanlarında (onlarca gigabayt ve üzeri) yavaşlamasıdır; çünkü her satırı tek tek SQL'e çevirir ve geri yüklerken tek tek işler. Pratik bir kural olarak: birkaç gigabayta kadar olan tipik WordPress, e-ticaret veya kurumsal uygulama veritabanları için mysqldump mükemmel bir seçimdir. Bu ölçek, paylaşımlı ve orta seviye hosting paketlerinin büyük çoğunluğunu kapsar. Çok daha büyük ve yüksek trafikli sistemlerde fiziksel yedek araçlarına geçmek gerekir.

Tek Bir Veritabanını Yedekleme#

En temel kullanım, tek bir veritabanını bir .sql dosyasına aktarmaktır. Komutun genel biçimi şudur:

mysqldump -u kullanici -p veritabani_adi > yedek.sql

Burada -u kullanıcı adını, -p ise şifre sorulmasını ister (şifreyi komuta yazmayın; Enter'a basınca sizden istenir). > işareti çıktıyı ekrana değil dosyaya yönlendirir. Gerçek bir örnekle, wp_site adlı veritabanını tarih içeren bir dosyaya alalım:

mysqldump -u root -p wp_site > wp_site_2026-07-10.sql

Komut bittiğinde elinizde tam bir SQL dosyası olur. İçini merak ederseniz ilk satırlarına bakabilirsiniz:

head -n 30 wp_site_2026-07-10.sql

Uzak bir sunucudaki veritabanını yedeklemek isterseniz -h ile host, -P ile port belirtirsiniz:

mysqldump -h db.ornek.com -P 3306 -u app_user -p app_db > app_db.sql

Yalnızca belirli tabloları almak da mümkündür. Örneğin sadece orders ve customers tablolarını yedeklemek için tablo adlarını veritabanının ardına yazın:

mysqldump -u root -p shop orders customers > shop_kritik_tablolar.sql

--single-transaction ile Tutarlı ve Kilitsiz Yedek#

Canlı bir sitede yedek alırken en sinsi problem tutarlılıktır. Yedek 20 saniye sürüyorsa ve bu sırada yeni siparişler geliyorsa, düz mysqldump tabloları kilitleyerek yazma işlemlerini bekletebilir; bu da ziyaretçi için sitenin donması demektir. InnoDB motorunu kullanan tablolar için bu sorunun çözümü --single-transaction seçeneğidir:

mysqldump --single-transaction -u root -p wp_site > wp_site.sql

Bu seçenek, yedeğin başında tek bir tutarlı "anlık görüntü" (snapshot) açar. mysqldump o andaki veriyi okurken siteye gelen yeni yazmalar arka planda normal şekilde devam eder; yedeğe ise başlangıç anındaki tutarlı durum yansır. Yani ne siteyi kilitlersiniz ne de yarısı eski yarısı yeni "bozuk" bir yedek alırsınız. Neredeyse tüm modern WordPress, Laravel ve benzeri uygulamalar InnoDB kullandığı için bu seçenek pratikte varsayılan tercihiniz olmalıdır.

Üretim ortamı için önerdiğimiz tam komut şu şekildedir:

mysqldump --single-transaction --quick --routines --triggers --events \
  -u root -p wp_site > wp_site.sql

Bu bayrakların ne işe yaradığını bir tabloyla özetleyelim:

Not olarak: eğer tablolarınız MyISAM motorunu kullanıyorsa --single-transaction işe yaramaz; onun yerine kısa süreli kilitleme yapan --lock-tables devreye girer. Hangi motoru kullandığınızı SHOW TABLE STATUS; ile görebilirsiniz. Veritabanı yönetiminin bu tarafını daha derinlemesine ele aldığımız MySQL veritabanı yönetimi rehberine de göz atmanızı öneririz.

Tüm Veritabanlarını Tek Seferde Yedekleme#

Sunucuda birden fazla site barındırıyorsanız her birini ayrı ayrı yedeklemek yerine hepsini tek komutta alabilirsiniz. --all-databases bayrağı sunucudaki tüm veritabanlarını tek dosyaya aktarır:

mysqldump --single-transaction --all-databases -u root -p > tum_veritabanlari.sql

Bu yaklaşım özellikle sunucu taşıma senaryolarında değerlidir: eski sunucudan tek dosya alır, yenisine tek komutla yüklersiniz. Ancak dikkat edilmesi gereken bir nokta var: --all-databases, mysql, information_schema ve performance_schema gibi sistem veritabanlarını da içerir. Aynı MySQL sürümüne taşıma yapıyorsanız bu genellikle sorun değildir, hatta kullanıcı ve yetki bilgilerini de taşıdığı için avantajlıdır. Farklı bir sürüme geçiyorsanız sistem veritabanlarını dışarıda bırakıp yalnızca kendi verilerinizi almanız daha güvenlidir.

Belirli birkaç veritabanını seçerek almak için --databases seçeneğini kullanın; bu, dosyaya CREATE DATABASE ifadelerini de ekler:

mysqldump --single-transaction --databases wp_site shop crm -u root -p > secili_db.sql

Sunucudaki veritabanlarını listeleyip her birini kendi ayrı dosyasına almak isterseniz kısa bir döngü işinizi görür:

for db in $(mysql -u root -p'SIFRE' -N -e 'SHOW DATABASES;' \
  | grep -Ev '^(mysql|sys|information_schema|performance_schema)$'); do
  mysqldump --single-transaction --quick "$db" -u root -p'SIFRE' > "${db}.sql"
done

Her veritabanının ayrı dosyada olması, ileride tek bir siteyi geri yüklemeniz gerektiğinde işinizi çok kolaylaştırır; devasa tek bir dosyanın içinden bir veritabanı ayıklamak zahmetlidir.

gzip ile Sıkıştırma ve Disk Tasarrufu#

SQL dosyaları düz metin olduğu için çok iyi sıkışır; tipik olarak boyutun onda birine kadar inebilir. Bu hem disk hem de yedekleri başka sunucuya taşırken bant genişliği tasarrufu demektir. Sıkıştırmayı ayrı bir adım olarak değil, doğrudan yedekleme sırasında boru (pipe) ile yaparsanız diske hiç sıkıştırılmamış dev dosya yazmamış olursunuz:

mysqldump --single-transaction wp_site -u root -p | gzip > wp_site.sql.gz

Buradaki | işareti mysqldump çıktısını doğrudan gzip'e aktarır, gzip de sıkıştırılmış halini dosyaya yazar. Sonuç genellikle ham dosyanın çok altında bir boyut olur. Daha yüksek sıkıştırma oranı isterseniz gzip -9 ya da çok çekirdekli sunucularda çok daha hızlı çalışan pigz'i kullanabilirsiniz:

mysqldump --single-transaction wp_site -u root -p | pigz > wp_site.sql.gz

Sıkıştırılmış bir yedeğin içeriğine bakmak için açmadan zcat kullanabilirsiniz:

zcat wp_site.sql.gz | head -n 20

Geri yükleme adımında da göreceğiniz gibi, sıkıştırılmış dosyayı diske açmadan doğrudan MySQL'e akıtabilirsiniz; bu da hem yer hem zaman kazandırır.

Yalnızca Şema veya Yalnızca Veri Alma#

Bazen tüm veriye değil sadece tabloların yapısına ihtiyaç duyarsınız: bir test ortamı kurarken, şema değişikliklerini gözden geçirirken veya bir geliştiriciye örnek bir iskelet verirken. -d (uzun hali --no-data) seçeneği yalnızca CREATE TABLE ifadelerini alır, tek bir satır veri koymaz:

mysqldump -d --routines wp_site -u root -p > wp_site_sema.sql

Bunun tersi de mümkündür. --no-create-info (kısa -t) yalnızca INSERT satırlarını, yani veriyi alır; tablo tanımlarını atlar. Bu, hedefte tablolar zaten varken sadece veriyi tazelemek istediğiniz durumlarda kullanışlıdır:

mysqldump -t wp_site -u root -p > wp_site_veri.sql

Verinin bir kısmını almak için --where koşulu koyabilirsiniz. Örneğin yalnızca son 30 günün loglarını yedeklemek gibi:

mysqldump wp_site logs --where="created_at >= NOW() - INTERVAL 30 DAY" \
  -u root -p > son30gun_log.sql

Aşağıdaki tablo bu üç yaklaşımı özetler:

Yedeği Geri Yükleme#

Yedek almak sadece işin yarısıdır; asıl önemli olan yedeği gerçekten geri yükleyebilmektir. Test etmediğiniz bir yedek, yedek sayılmaz. mysqldump çıktısı sıradan SQL komutları olduğu için geri yükleme, dosyayı mysql istemcisine beslemekten ibarettir. Önce hedef veritabanının var olduğundan emin olun:

mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS wp_site CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

Ardından yedeği bu veritabanına yükleyin. > yazma yönü yerine burada < okuma yönünü kullanırız:

mysql -u root -p wp_site < wp_site_2026-07-10.sql

Eğer yedeğiniz gzip ile sıkıştırılmışsa önce açıp sonra yüklemek yerine tek boruyla akıtabilirsiniz:

gunzip < wp_site.sql.gz | mysql -u root -p wp_site

--databases veya --all-databases ile alınmış bir yedek zaten kendi CREATE DATABASE ve USE ifadelerini içerdiği için hedef veritabanı adını belirtmenize gerek kalmaz:

mysql -u root -p < tum_veritabanlari.sql

Büyük bir dosyayı yüklerken ilerlemeyi görmek isterseniz pv aracı çok işe yarar; yükleme çubuğu ve tahmini süre gösterir:

pv wp_site.sql.gz | gunzip | mysql -u root -p wp_site

Geri yükleme sonrası mutlaka birkaç kontrol yapın: satır sayılarını (SELECT COUNT(*) FROM ...), en son eklenen kaydın tarihini ve uygulamanın açılıp açılmadığını doğrulayın. Bu doğrulama alışkanlığı, gerçek bir felaket anında sizi çok büyük bir stresten kurtarır.

cron ile Otomatik ve Tarih Damgalı Yedekleme#

Elle alınan yedek, unutulan yedektir. Sürdürülebilir tek yol, yedeklemeyi zamanlanmış bir göreve dönüştürmektir. Önce yedekleme mantığını küçük bir betiğe koyalım. Aşağıdaki betik veritabanını tarih damgalı olarak sıkıştırıp kaydeder ve 14 günden eski yedekleri otomatik siler:

#!/bin/bash
set -euo pipefail

DB="wp_site"
DIR="/var/backups/mysql"
TARIH=$(date +%F_%H-%M)
DOSYA="$DIR/${DB}_${TARIH}.sql.gz"

mkdir -p "$DIR"

mysqldump --single-transaction --quick --routines --triggers \
  --defaults-extra-file=/root/.my.cnf "$DB" | gzip > "$DOSYA"

# 14 gunden eski yedekleri temizle
find "$DIR" -name "${DB}_*.sql.gz" -mtime +14 -delete

Dikkat ettiyseniz şifreyi komuta yazmadık. Bunun yerine --defaults-extra-file ile ayrı bir kimlik dosyası kullandık. Şifrelerin cron loglarında ve süreç listesinde görünmemesi için doğru yöntem budur. /root/.my.cnf dosyasını şu içerikle oluşturun ve izinlerini kısıtlayın:

[client]
user=root
password=COK_GIZLI_SIFRE

chmod 600 /root/.my.cnf

Betiği çalıştırılabilir yapın ve elle bir kez deneyin:

chmod +x /usr/local/bin/db-yedek.sh
/usr/local/bin/db-yedek.sh

Sorunsuz çalıştığını gördükten sonra crontab -e ile zamanlayın. Aşağıdaki satır her gece saat 03.30'da yedek alır:

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

Buradaki beş alan sırasıyla dakika, saat, ayın günü, ay ve haftanın günüdür. Çıktıyı bir log dosyasına yönlendirmek, ileride bir gece yedeğin neden başarısız olduğunu anlamak için altın değerindedir. Trafiğin en düşük olduğu saatleri seçmek, --single-transaction kullansanız bile sunucu yükünü minimumda tutar.

Yedekleri Dışarı Taşıma ve Saklama Politikası#

Yedeği aynı sunucuda tutmak, yarım bir güvenliktir. Diskin bozulduğu, sunucunun ele geçirildiği ya da veri merkezinde bir sorun çıktığı bir senaryoda yerel yedekler de kaybolur. Bu yüzden altın kural "3-2-1"dir: verinin en az üç kopyası, iki farklı ortamda ve bir tanesi mutlaka farklı bir fiziksel konumda bulunmalıdır. Uygulamada bu, gece alınan yedeği başka bir sunucuya ya da nesne depolamasına kopyalamak demektir.

En pratik yöntem, betiğin sonuna bir kopyalama adımı eklemektir. rsync ile uzak bir sunucuya senkronize edebilirsiniz:

rsync -avz --delete /var/backups/mysql/ \
  [email protected]:/yedekler/mysql/

rsync yalnızca değişen dosyaları aktardığı için ağ kullanımını en aza indirir; bu aracı ayrıntılı ele aldığımız rsync ile yedekleme rehberinde dizin bütünlüğü ve zamanlama konularını da bulabilirsiniz. Bir alternatif olarak scp ile tek dosyayı da gönderebilirsiniz:

scp /var/backups/mysql/wp_site_$(date +%F)*.sql.gz \
  [email protected]:/yedekler/

Saklama politikanızı katmanlı düşünün: günlük yedekleri 14 gün, haftalıkları birkaç ay, aylıkları bir yıl tutmak gibi. Bu dengeyi kurmak, hem eski bir hatayı fark ettiğinizde geriye gidebilmenizi hem de diskin sonsuza dek şişmemesini sağlar. Aşağıdaki tablo makul bir başlangıç şeması sunar:

Bu düzeni kurmakla uğraşmak istemez ve yönetilen bir çözüm ararsanız, otomatik yedekleme hizmetimiz sunucu ve veritabanı yedeklerinizi sizin adınıza düzenli olarak alır ve dışarıda saklar. Sunucu tarafında tüm bu kurulumları sizin yerinize yapmamızı isterseniz sunucu yönetimi paketimiz de bu tür bakım işlerini kapsar.

Sıkça Sorulan Sorular#

mysqldump sırasında sitem yavaşlar mı, kilitlenir mi?#

InnoDB tabloları kullanıyorsanız ve --single-transaction seçeneğini eklerseniz siteniz kilitlenmez; yedek tutarlı bir anlık görüntü üzerinden alınır ve ziyaretçiler bu sırada normal şekilde işlem yapmaya devam eder. Sitenin donması genellikle bu seçenek olmadan alınan yedeklerde ya da MyISAM tablolarında yaşanır. Yükü tümüyle görünmez kılmak için yedekleri trafiğin en düşük olduğu gece saatlerine planlamanız yeterlidir.

Şifremi komuta yazmadan yedek nasıl alırım?#

Şifreyi -p bayrağının yanına yazmak, hem terminal geçmişinde hem de çalışan süreç listesinde görünmesine yol açar ve güvenlik açığı oluşturur. Doğru yöntem, kimlik bilgilerini /root/.my.cnf gibi izinleri 600 olan bir dosyaya koyup komuta --defaults-extra-file=/root/.my.cnf eklemektir. Böylece mysqldump şifreyi bu dosyadan okur ve otomatik cron görevlerinde de sorunsuz çalışır.

Yedek dosyam çok büyük, boyutunu nasıl küçültürüm?#

En kolay yol, çıktıyı doğrudan gzip ile sıkıştırmaktır; SQL metni çok iyi sıkıştığı için dosya genellikle onda bir boyutuna kadar iner. Bunu mysqldump ... | gzip > yedek.sql.gz biçiminde boru kullanarak yaparsanız diske hiç sıkıştırılmamış büyük dosya yazılmamış olur. Ayrıca yalnızca ihtiyaç duyduğunuz tabloları ya da --where ile son dönem verisini alarak da boyutu düşürebilirsiniz.

mysqldump yedeğini farklı bir MySQL sürümüne geri yükleyebilir miyim?#

Genellikle evet; mysqldump çıktısı standart SQL olduğu için MySQL ve MariaDB sürümleri arasında büyük ölçüde taşınabilir. En sağlıklısı eski sürümden yeni sürüme doğru yükleme yapmaktır ve --all-databases yerine yalnızca kendi veritabanlarınızı alarak sistem tablolarını dışarıda bırakmaktır. Farklı sürümlerde karakter seti ya da eski söz dizimi kaynaklı küçük uyarılar çıkabilir; bu yüzden taşımayı önce bir test ortamında denemenizi öneririz.

Aldığım yedeğin sağlam olduğunu nasıl anlarım?#

Bir yedeğe gerçekten güvenmenin tek yolu, onu boş bir test veritabanına geri yükleyip içeriğini doğrulamaktır. Yükledikten sonra kritik tabloların satır sayılarını kontrol edin, en son eklenen kaydın tarihine bakın ve mümkünse uygulamayı bu test veritabanına bağlayıp açıldığını görün. Bu "geri yükleme tatbikatını" ayda bir yapmak, gerçek bir felaket anında yedeğinizin işe yarayacağından emin olmanızı sağlar.

Sadece bir tabloyu yanlışlıkla sildim, tüm veritabanını geri yüklemem şart mı?#

Hayır. mysqldump çıktısı düz metin olduğu için içinden yalnızca ilgili tablonun CREATE TABLE ve INSERT satırlarını ayıklayıp onu geri yükleyebilirsiniz. Daha temiz bir yaklaşım, her tabloyu ayrı dosyada tutan bir yedek stratejisi ya da geri yükleme öncesi yedeği geçici bir veritabanına açıp yalnızca ihtiyacınız olan tabloyu asıl veritabanına kopyalamaktır. Bu yüzden kritik sistemlerde veritabanlarını ayrı dosyalara almak ileride hayat kurtarır.

Kapanış#

mysqldump, sadeliğinin arkasında ciddi bir güç barındıran bir araçtır: tek satırlık bir komutla tutarlı, taşınabilir ve okunabilir bir yedek üretir. Bu rehberde tek ve toplu yedeklemeyi, --single-transaction ile kilitsiz tutarlılığı, gzip sıkıştırmasını, yalnız şema veya yalnız veri almayı, geri yüklemeyi ve cron ile tarih damgalı otomatik yedekleri ele aldık. Bunları bir kez kurup dışarı taşıma adımını da eklediğinizde, veri kaybı korkusunu büyük ölçüde arkanızda bırakırsınız. Unutmayın: en iyi yedek, düzenli alınan ve düzenli test edilen yedektir.

Clou.TR olarak veritabanlarınızın güvenliğini şansa bırakmamanız için buradayız. Otomatik ve dış lokasyonda saklanan yedekler için yedekleme çözümümüze, sunucu bakımını bize devretmek için sunucu yönetimi hizmetimize, performanslı bir altyapı için VDS sunucularımıza ve WordPress projeleriniz için WordPress hosting paketlerimize göz atabilirsiniz. Kurulum ya da geri yükleme konusunda takıldığınız her noktada uzman ekibimiz yanınızda.