Percona XtraBackup ile Sıcak Yedekleme

Veritabanın 5 gigabayt olduğu sürece mysqldump her gece sorunsuz çalışır. 150 gigabayta ulaştığında ise dump saatler sürmeye başlar, geri yükleme daha da uzun sürer ve yedek alınırken sunucu gözle görülür biçimde yavaşlar. Percona XtraBackup ile sıcak yedekleme tam bu noktada devreye girer: MySQL çalışmaya devam ederken InnoDB veri dosyalarını doğrudan kopyalar, kopyalama sırasında değişen sayfaları redo log üzerinden yakalar ve sonunda tutarlı bir fiziksel yedek üretir.

Bu rehberde XtraBackup'ı kuracak, gerekli yetkileri vereceğiz; ilk tam yedeği alıp prepare adımının neden zorunlu olduğunu göreceğiz; yedeği bir sunucuya geri yükleyeceğiz; artımlı yedeklerle günlük disk maliyetini düşüreceğiz ve son olarak sıkıştırarak doğrudan uzak sunucuya akıtmayı ele alacağız. Sık yapılan hatalara ayrı bir bölüm var, çünkü XtraBackup'ta hataların çoğu yedek alınırken değil, geri yüklemeye kalkıldığında ortaya çıkar — yani en kötü anda.

Sıcak Yedekleme ile Mantıksal Yedeğin Farkı#

mysqldump bir mantıksal yedek üretir: veriyi okuyup INSERT ifadelerine dönüştürür. Geri yüklerken bu ifadeler tek tek çalıştırılır, indeksler baştan inşa edilir. Küçük veri setlerinde bu gayet iyidir; taşınabilirdir, metin dosyasıdır, içini okuyabilirsin. Ama boyut büyüdükçe geri yükleme süresi doğrusal değil, daha kötü ölçeklenir.

XtraBackup ise fiziksel bir yedek alır: InnoDB'nin tablo alanı dosyalarını (.ibd) ve redo log'unu olduğu gibi kopyalar. Geri yüklerken hiçbir sorgu çalıştırılmaz, indeks yeniden inşa edilmez; dosyalar veri dizinine geri konur ve MySQL başlatılır. Bu yüzden geri yükleme, dump'a kıyasla kat kat hızlıdır.

Buradaki son iki satır önemli. XtraBackup ile alınan yedeği farklı bir ana sürüme geri yükleyemezsin; MySQL 8.0'dan alınan yedek 5.7 sunucusuna gitmez. Ayrıca tek bir tabloyu kurtarmak, dump'ta bir grep işiyken XtraBackup'ta ek adımlar ister. Bu yüzden en sağlıklı strateji ikisini birlikte kullanmaktır: günlük fiziksel yedek hız için, haftalık mantıksal yedek taşınabilirlik ve tekil kurtarma için. mysqldump ile veritabanı yedekleme yazısı ikinci yarıyı anlatıyor.

Kurulum ve Yedekleme Kullanıcısını Yetkilendirme#

XtraBackup, MySQL'in ana sürümüne uygun olan sürümüyle kurulmalıdır. MySQL 8.x için XtraBackup 8.x, MySQL 5.7 için 2.4 serisi kullanılır. MariaDB kullanıyorsan XtraBackup yerine MariaDB'nin kendi çatalı olan mariabackup doğru araçtır; komut sözdizimi neredeyse birebir aynıdır.

# Percona deposunu ekle ve XtraBackup 8'i kur
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
sudo percona-release enable-only tools release
sudo apt update
sudo apt install -y percona-xtrabackup-80 qpress

xtrabackup --version

qpress paketi, sıkıştırmalı yedeklerin açılması için gereklidir; şimdi kurmazsan geri yükleme anında ararsın. Ardından yalnızca yedekleme için ayrı bir kullanıcı oluştur. Root ile yedek almak yaygın ama gereksiz bir risktir:

CREATE USER 'yedekci'@'localhost' IDENTIFIED BY 'GucluBirParola';
GRANT BACKUP_ADMIN, RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT
  ON *.* TO 'yedekci'@'localhost';
GRANT SELECT ON performance_schema.log_status TO 'yedekci'@'localhost';
FLUSH PRIVILEGES;

MySQL 8'de BACKUP_ADMIN yetkisi, LOCK INSTANCE FOR BACKUP komutunu kullanabilmek için gereklidir; bu komut eski sürümlerdeki global okuma kilidinin yerini alır ve çok daha az müdahalecidir. Yetki modeliyle ilgili ayrıntıya girmek istersen MySQL kullanıcı ve yetki yönetimi yazısında nesne bazlı GRANT örneklerini bulabilirsin.

İlk Tam Yedeği Almak#

Tam yedek tek bir komuttan ibarettir. Hedef dizinin boş olması gerekir; XtraBackup var olan bir dizine yazmayı reddeder.

sudo mkdir -p /yedek/tam-$(date +%F)

sudo xtrabackup --backup \
  --user=yedekci --password='GucluBirParola' \
  --target-dir=/yedek/tam-$(date +%F) \
  --parallel=4

--parallel=4 dosya kopyalamayı dört iş parçacığına dağıtır ve büyük veri setlerinde süreyi belirgin biçimde kısaltır; sunucunun çekirdek sayısını aşmamaya dikkat et. Komut başarıyla bittiğinde son satırda completed OK! görürsün; bu ifadeyi görmediysen yedek kullanılamaz kabul edilmelidir.

Yedek dizininde birkaç küçük metin dosyası oluşur ve bunlar en az veri dosyaları kadar değerlidir:

ls /yedek/tam-2026-08-25/ | head
# ibdata1
# mysql/
# magaza/
# xtrabackup_binlog_info
# xtrabackup_checkpoints
# xtrabackup_info

cat /yedek/tam-2026-08-25/xtrabackup_checkpoints
# backup_type = full-backuped
# from_lsn = 0
# to_lsn = 4218977326
# last_lsn = 4218977335

xtrabackup_binlog_info dosyası, yedeğin alındığı andaki binlog dosyası ve konumunu tutar. Bu iki değer, ilerideki bir kurtarmada binlog'u yedeğin üzerine uygulamanı sağlar; binlog ile point-in-time recovery yazısı bu akışın devamıdır. xtrabackup_checkpoints içindeki to_lsn değeri ise artımlı yedeklerin başlangıç noktasıdır.

Yedeği doğrulamak için son satırı otomatik kontrol etmek iyi bir alışkanlıktır:

sudo xtrabackup --backup --user=yedekci --password='Parola' \
  --target-dir=/yedek/tam-$(date +%F) 2>&1 | tee /var/log/xtrabackup.log

grep -q "completed OK" /var/log/xtrabackup.log && echo "YEDEK TAMAM" || echo "YEDEK BAŞARISIZ"

Prepare Adımı ve Geri Yükleme#

XtraBackup yedek alırken MySQL çalışmaya devam eder, dolayısıyla kopyalanan dosyalar farklı anlara ait sayfalar içerir — yani tutarsızdır. prepare adımı, kopyalanan redo log'u dosyalara uygulayarak bu tutarsızlığı giderir ve yedeği "başlatılabilir" hâle getirir. Bu adımı atlarsan yedeğin hiçbir işe yaramaz.

sudo xtrabackup --prepare --target-dir=/yedek/tam-2026-08-25

Bu komut da completed OK! ile bitmelidir. Prepare işlemi RAM kullanır; büyük veri setlerinde --use-memory=4G gibi bir değer vererek hızlandırabilirsin. Prepare'i yedek alır almaz yapmanı öneririm; kurtarma anında hem zaman kazanırsın hem de yedeğin sağlam olduğunu o an öğrenirsin.

Geri yükleme sırasıyla şu adımlardan oluşur:

1. MySQL'i durdur. Çalışan bir sunucunun veri dizinine dosya kopyalamak veriyi bozar.

sudo systemctl stop mysql

2. Mevcut veri dizinini boşalt. Silmek yerine yeniden adlandırmak, geri dönebilmek açısından çok daha akıllıcadır:

sudo mv /var/lib/mysql /var/lib/mysql-eski-$(date +%s)
sudo mkdir /var/lib/mysql

3. Yedeği geri kopyala.

sudo xtrabackup --copy-back --target-dir=/yedek/tam-2026-08-25

--copy-back yedeği olduğu yerde bırakıp kopyalar; disk alanın kısıtlıysa --move-back taşır ama yedeği tüketir, bu yüzden yalnızca elinde ikinci bir kopya varken kullan.

4. Dosya sahipliğini düzelt. Bu adımı unutmak, geri yüklemede yaşanan en yaygın hatadır:

sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl start mysql
mysql -e "SELECT COUNT(*) FROM magaza.siparis;"

MySQL başlamıyorsa ilk bakacağın yer hata günlüğüdür (/var/log/mysql/error.log); izin sorunları ve eksik prepare adımı buradaki mesajlardan hemen anlaşılır.

Artımlı Yedekleme ile Disk ve Süre Tasarrufu#

Her gün 150 gigabaytlık tam yedek almak hem diski hem de zamanı israf eder. XtraBackup, InnoDB'nin LSN (log sequence number) sayacını kullanarak yalnızca son yedekten bu yana değişmiş sayfaları kopyalayabilir. Pratikte günlük değişim oranı yüzde birkaç olduğu için artımlı yedekler çok küçük kalır.

Pazar günü tam yedeği aldığını varsayalım. Pazartesi artımlı yedeği şöyle alırsın:

sudo xtrabackup --backup \
  --user=yedekci --password='Parola' \
  --target-dir=/yedek/art-pazartesi \
  --incremental-basedir=/yedek/tam-2026-08-25

Salı günü ise temel dizin olarak pazartesinin artımlı yedeğini verirsin; böylece zincir uzar:

sudo xtrabackup --backup \
  --user=yedekci --password='Parola' \
  --target-dir=/yedek/art-sali \
  --incremental-basedir=/yedek/art-pazartesi

Geri yükleme sırasında zinciri doğru sırayla birleştirmen gerekir ve burada kritik bir parametre var: ara adımlarda --apply-log-only kullanılır, yalnızca son adımda kullanılmaz.

# 1) Tam yedeği yarı hazırla (geri alma işlemlerini uygulama)
sudo xtrabackup --prepare --apply-log-only --target-dir=/yedek/tam-2026-08-25

# 2) Pazartesiyi üzerine ekle, yine --apply-log-only ile
sudo xtrabackup --prepare --apply-log-only \
  --target-dir=/yedek/tam-2026-08-25 \
  --incremental-dir=/yedek/art-pazartesi

# 3) SON adım: --apply-log-only YOK
sudo xtrabackup --prepare \
  --target-dir=/yedek/tam-2026-08-25 \
  --incremental-dir=/yedek/art-sali

Son adımda --apply-log-only kullanırsan yarım kalmış işlemler geri alınmaz ve veri tabanı tutarsız kalır. Bu, artımlı zincirdeki en sık yapılan hatadır. Zincirin ne kadar uzayacağına da dikkat et: yedi günlük bir zincirde altıncı günün yedeği bozulursa sonraki günlerin hepsi kullanılamaz hâle gelir. Haftada bir tam yedek almak bu riski sınırlar.

Sıkıştırma, Akış ve Uzak Sunucuya Yedekleme#

Yedeği aynı diskte tutmak, disk arızasına karşı hiçbir koruma sağlamaz. XtraBackup çıktısını doğrudan bir akışa yazabilir ve bu akışı sıkıştırıp uzak sunucuya gönderebilirsin. Böylece yerelde geçici alan da tüketmezsin.

# Sıkıştırarak tek dosyaya al
sudo xtrabackup --backup --user=yedekci --password='Parola' \
  --stream=xbstream --parallel=4 \
  | gzip > /yedek/tam-$(date +%F).xbstream.gz

# Doğrudan uzak sunucuya akıt
sudo xtrabackup --backup --user=yedekci --password='Parola' \
  --stream=xbstream --parallel=4 \
  | ssh [email protected] "xbstream -x -C /yedek/mysql/$(date +%F)"

Sıkıştırılmış bir akışı geri açmak için önce arşivi çıkarır, sonra normal prepare akışına devam edersin:

mkdir -p /yedek/acilan
gunzip -c /yedek/tam-2026-08-25.xbstream.gz | xbstream -x -C /yedek/acilan
sudo xtrabackup --prepare --target-dir=/yedek/acilan

XtraBackup'ın kendi sıkıştırmasını da kullanabilirsin (--compress), bu durumda geri açmak için --decompress adımı gerekir ve qpress paketi şart olur. Pratikte gzip ya da zstd ile borulamak hem daha esnek hem de daha anlaşılırdır. Yedekleri farklı bir fiziksel konumda saklamak istiyorsan yedekleme hizmetimiz bu kopyalamayı zamanlanmış olarak üstlenir; kendi ikinci sunucunu kurmak istersen bulut sunucu paketleri uygun bir hedef olur.

Sık Yapılan Hatalar ve Dikkat Edilecekler#

Birinci hata, prepare adımını atlayıp yedeği doğrudan geri yüklemeye çalışmaktır. Hazırlanmamış bir yedek tutarsızdır ve MySQL genellikle hiç başlamaz. Yedek alır almaz prepare çalıştırmayı rutinine ekle.

İkinci hata, chown mysql:mysql komutunu unutmaktır. --copy-back dosyaları root olarak kopyalar ve MySQL kendi veri dizinini okuyamaz. Hata günlüğünde "Permission denied" satırları görürsün; çözüm tek komuttur ama akla gelmesi zaman alır.

Üçüncü hata, MyISAM tablolarını unutmaktır. XtraBackup yalnızca InnoDB için gerçekten sıcaktır; MyISAM ve diğer motorlardaki tablolar yedeğin sonunda kısa süreli bir kilitle kopyalanır. Veritabanında büyük MyISAM tabloları varsa bu kilit süresi uzayabilir. Motorları kontrol et ve mümkünse hepsini InnoDB'ye taşı:

SELECT table_schema, table_name, engine, ROUND(data_length/1024/1024) AS mb
FROM information_schema.tables
WHERE engine NOT IN ('InnoDB') AND table_schema NOT IN
  ('mysql','information_schema','performance_schema','sys')
ORDER BY data_length DESC;

Dördüncü hata, sürüm uyumsuzluğudur. XtraBackup 8.0 ile alınan bir yedek MySQL 5.7'ye geri yüklenemez; hatta bazı ara sürümler arasında da uyumsuzluk çıkabilir. Sunucu sürümünü yükseltmeyi planlıyorsan geçiş öncesinde ayrıca bir mantıksal yedek al. Yükseltme sürecinin kendisi için MySQL 5.7'den 8.4'e yükseltme yazısı yol haritası sunar.

Beşinci ve en tehlikeli hata, yedeği hiç test etmemektir. completed OK! yazması yedeğin geri yüklenebileceğini garanti etmez; tek gerçek kanıt, o yedekten ayağa kalkmış çalışan bir MySQL örneğidir. Ayda bir kez, boş bir sunucuya son yedeği geri yükle ve satır sayılarını karşılaştır. Bu provanın süresini ölçmek aynı zamanda gerçekçi bir kurtarma hedefi belirlemeni sağlar.

Sıkça Sorulan Sorular#

XtraBackup MariaDB ile çalışır mı#

Doğrudan çalışmaz. MariaDB, XtraBackup'ın bir çatalı olan mariabackup aracını kendi dağıtımıyla birlikte sunar ve MariaDB sunucularında bu araç kullanılmalıdır. Komut yapısı ve parametreler neredeyse birebir aynıdır, bu rehberdeki akışı xtrabackup yerine mariabackup yazarak uygulayabilirsin. Galera kurulumlarında SST yöntemi olarak da yine mariabackup tercih edilir.

XtraBackup yedek alırken site yavaşlar mı#

InnoDB tabloları için gözle görülür bir kilitlenme olmaz, ancak yedekleme diskten yoğun okuma yapar ve bu, disk üzerinde rekabete yol açabilir. Yoğun saatlerde yedek almak yerine trafiğin düşük olduğu bir pencere seçmek en pratik çözümdür. Etkiyi azaltmak için --throttle parametresiyle saniyedeki okuma hızını sınırlayabilir ya da yedeği bir replika üzerinde alarak asıl sunucuya hiç dokunmayabilirsin.

Artımlı yedek zinciri en fazla kaç gün olmalı#

Zincir uzadıkça hem geri yükleme süresi hem de zincirin ortasında bir dosyanın bozulma riski artar. Yaygın pratik, haftada bir tam yedek alıp aradaki altı günü artımlı ilerletmektir. Değişim oranı çok yüksek bir sistemde artımlı yedekler tam yedeğe yaklaşmaya başlar; bu noktada artımlı almanın anlamı kalmaz ve daha sık tam yedek almak daha mantıklı olur.

Yedeğin sağlam olduğunu nasıl kontrol ederim#

İlk kontrol, komut çıktısının son satırında completed OK! ifadesinin bulunmasıdır; bu satır yoksa yedek geçersizdir. Ancak asıl doğrulama geri yükleme provasıdır: yedeği ayrı bir sunucuya veya farklı bir porttaki ikinci MySQL örneğine geri yükleyip birkaç tablonun satır sayısını üretimle karşılaştır. Otomatik bir betikle ayda bir bu provayı yapmak, yedekleme stratejisinin gerçekten çalıştığının tek kanıtıdır.

Tek bir tabloyu XtraBackup yedeğinden geri getirebilir miyim#

Mümkün ama zahmetlidir. Yöntem, yedeği ayrı bir MySQL örneğine tam olarak geri yüklemek ve oradan yalnızca ihtiyacın olan tabloyu mysqldump ile alıp üretime aktarmaktır. Doğrudan tablo alanı taşıma yöntemi de vardır ancak tablo yapılarının birebir eşleşmesini gerektirir ve hataya açıktır. Tekil tablo kurtarma ihtiyacı sıksa, fiziksel yedeğin yanında haftalık mantıksal yedek tutmak çok daha pratiktir.

XtraBackup ücretsiz mi#

Percona XtraBackup açık kaynaktır ve GPL lisansıyla ücretsiz dağıtılır; üretimde kullanmak için lisans ücreti ödemezsin. Tüm özellikler, artımlı yedekleme ve sıkıştırma dahil, ücretsiz sürümde bulunur. Percona yalnızca destek ve danışmanlık paketleri için ücret alır. MariaDB tarafındaki karşılığı olan mariabackup da aynı şekilde açık kaynaktır.

Kapanış#

XtraBackup, büyüyen bir veritabanında yedekleme penceresini makul tutmanın ve kurtarma süresini dramatik biçimde kısaltmanın en pratik yoludur. Aklında kalması gereken alışkanlıklar şunlar: her yedekten sonra completed OK! satırını otomatik kontrol et, prepare adımını yedek alır almaz çalıştır, artımlı zincirde son adım hariç daima --apply-log-only kullan ve geri yüklemeden sonra chown mysql:mysql komutunu asla atlama. Bir de yedeği aynı diskte bırakma; farklı bir makinede duran kopya, gerçek koruma sağlayan tek kopyadır.

Bu akışı kurmak için root erişimli bir ortama ihtiyacın var; VDS ve bulut sunucu paketlerimizle Percona depolarını ekleyip yedekleme zincirini kendin kurabilirsin. Yedekleri düzenli olarak sunucu dışına almak istersen yedekleme hizmetimiz bu işi zamanlanmış şekilde üstlenir; kurulum, izleme ve geri yükleme provalarını uzman gözüyle yürütmek istersen sunucu yönetimi hizmetimize göz atabilirsin.