mariadb-backup ile Fiziksel Yedekleme ve Geri Yükleme

mariadb-backup nedir, ne değildir?

Belgelere göre mariadb-backup, InnoDB, Aria ve MyISAM tabloları için fiziksel ve çevrimiçi yedek alan açık kaynaklı bir araçtır; InnoDB için 'sıcak' yani sunucu çalışırken yedek mümkündür. Percona XtraBackup 2.3.8'den çatallanmıştır ve onun özelliklerine ek olarak veri dosyası şifrelemesi (data-at-rest encryption), InnoDB sayfa sıkıştırması, MyRocks ve Windows desteği getirir. Eski adı mariabackup'tır. Percona XtraBackup ise MariaDB'de desteklenmez; belgeler onun yerine mariadb-backup kullanılmasını önerir.

Fiziksel yedeğin artısı hızdır: dosyalar doğrudan kopyalandığı için mantıksal yedekten daha küçük ve daha hızlıdır. Eksisi esnekliktir: belgeler fiziksel yedeğin çok farklı donanımda, başka bir veritabanı sisteminde ya da muhtemelen farklı bir MariaDB sürümünde açılamayabileceğini belirtir. Bu yüzden bir sürümden diğerine geçerken yedeği aldığınız sürümle uyumlu mariadb-backup kullanmanız gerekir (aşağıda ayrıntısı var). MariaDB Enterprise Server ile gelen Enterprise Backup'ın ek kilit azaltma özellikleri bu serinin konusu dışında; burada Community Server'daki aracı anlatıyoruz.

Kurulum

Linux dağıtımlarının çoğu aracı paket olarak sunar; sunmuyorsa MariaDB deposunu ekleyip kurabilirsiniz (depo kurulumu için MariaDB kurulumu yazısına bakın). Belgelerdeki paket adları dağıtıma göre değişir: Debian ve Ubuntu'da mariadb-backup, RHEL ve benzerleri ile SLES'te MariaDB-backup. Windows'ta araç MSI ve ZIP paketlerinin içindedir.

sudo apt-get install mariadb-backup
sudo yum install MariaDB-backup
sudo zypper install MariaDB-backup

Yedek kullanıcısı ve izinler

--backup sırasında araç çalışan sunucuya bağlanır, çünkü kilitleri ve yedek aşamalarını sunucuyla birlikte yönetir. Belgeler bunun için ayrı bir kullanıcı açılmasını önerir ve çoğu durumda gereken genel yetkileri şöyle listeler:

CREATE USER 'mariadb-backup'@'localhost' IDENTIFIED BY 'mypassword';
GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'mariadb-backup'@'localhost';

Bazı seçenekler ek yetki ister. --kill-long-queries-timeout sıfırdan büyükse ve --no-lock kullanılmıyorsa CONNECTION ADMIN, --slave-info veya --galera-info kullanılıyorsa REPLICA MONITOR, MyRocks varsa SUPER gerekir. --history özelliği için de geçmiş tablosunda yetki gerekir (aşağıda). Hazırlama (--prepare) ve geri yükleme adımlarında ise sunucuya bağlanılmaz; bu yüzden kullanıcı bilgisi gerekmez.

Kullanıcı adı ve parola komut satırında --user ve --password ile verilebilir, ama bunları seçenek dosyasındaki [mariadb-backup] grubuna yazmak daha temizdir. Belgelere göre MariaDB 11.4.1 ve bazı eski kollardaki belirli sürümlerden itibaren --user verilmezse kullanıcı adı işletim sisteminden alınır.

[mariadb-backup]
user=mariadb-backup
password=mypassword

Araç veri dosyalarını doğrudan okuduğu için onu çalıştıran işletim sistemi kullanıcısının bu dosyalara erişebilmesi gerekir. Paket yöneticisiyle kurulmuş bir sistemde dosyalar genellikle mysql kullanıcısına ve grubuna aittir. Kullanıcı ve yetki konusu için CREATE USER ve GRANT yazılarına bakabilirsiniz.

Araç arka planda ne yapar?

Belgelerdeki 'How mariadb-backup Works' sayfası aşamaları sırayla anlatır ve --prepare adımının neden zorunlu olduğunu anlamak için bu sırayı bilmek faydalıdır:

• Başlangıç: Araç sunucuya bağlanır, veri dizinini, InnoDB sayfa boyutunu ve şifreleme ayarlarını öğrenir, veri dizinindeki InnoDB tablo alanlarını tarar.
• Redo log kopyası: Ayrı bir iş parçacığı InnoDB redo log'unu kopyalamaya başlar. Yedek sürerken yapılan bütün değişiklikler böylece kaydedilir. Belgeler bu iş parçacığının, redo log yeterince büyükse sunucuya yetişebileceğini varsayar.
• InnoDB dosyalarının kopyası: Tablo alanları dosya dosya, sayfa sağlama toplamları kontrol edilerek kopyalanır. Veri kopyalama sırasında değiştiği için bu dosyalar tek bir ana göre tutarlı değildir.
• Tutarlı nokta: Varsayılan olarak FLUSH TABLES WITH READ LOCK çalıştırılır; amaç, depolama motorundan bağımsız olarak bütün tabloları aynı anda tutarlı hâle getirmektir.
• Son kopya: .frm, MyISAM, Aria ve diğer motor dosyaları kopyalanır, redo log'un kalanı alınır, binary log konumu gibi üst veriler yazılır.
• Kilitlerin bırakılması: UNLOCK TABLES ile genel kilit kaldırılır.

Sonuçta hedef dizinde, farklı anlarda kopyalanmış veri dosyaları ile o süre boyunca biriken redo log bulunur. --prepare bu redo log'u dosyalara uygulayarak hepsini aynı ana getirir. Hazırlanmamış dosyalardan geri yüklemeye kalkarsanız belgelere göre InnoDB tutarsızlığı fark eder ve veriyi bozulmaya karşı korumak için çöker.

Tam yedek almak

Tam yedek için --backup ve hedef dizini gösteren --target-dir yeterlidir. Hedef dizin boş olmalı ya da hiç var olmamalıdır; araç yoksa oluşturur, dosya içeren bir dizin görürse hata verip durur. Yedek veritabanını değiştirmediği için gerekirse yarıda kesebilirsiniz.

mariadb-backup --backup \
   --target-dir=/var/mariadb/backup/ \
   --user=mariadb-backup --password=mypassword

Hedef dizinde veri dosyalarının yanında araçtan gelen birkaç dosya oluşur. MariaDB 11.1'den itibaren bunların adları mariadb_backup_ ile başlar; daha eski sürümlerde xtrabackup_ öneki kullanılır. backup-my.cnf, hazırlama aşamasında yeniden okunmak üzere sunucunun ilgili ayarlarını tutar. mariadb_backup_checkpoints yedeğin türünü ve LSN aralığını, mariadb_backup_binlog_info ise yedeğe karşılık gelen binary log dosya adını, konumunu ve GTID değerini içerir.

Yedeği hazırlamak (--prepare)

mariadb-backup --prepare \
   --target-dir=/var/mariadb/backup/

Hazırlama adımında sürüm uyumu kritiktir. Belgeler, yedeği hangi sunucu sürümünden alıyorsanız onunla uyumlu bir mariadb-backup kullanmanız gerektiğini örnekle anlatır: 10.6'dan 10.11'e yükselirken yedeği ve hazırlamayı 10.6'nın aracıyla, 10.11'den 11.4'e yükselirken 10.11'in aracıyla yapmalısınız. Yükseltme öncesi yedek alıyorsanız bu kuralı atlamayın; ayrıntılar sürüm yükseltme yazısında.

--use-memory seçeneği hazırlama sırasında kullanılacak tampon havuzu boyutunu belirler (örneğin --use-memory=124M); belgelere göre sunucudaki tampon havuzu ayarı yerine bu seçenek kullanılır. Belgeler şifreli tablolarla ilgili bir ayrıntıya da dikkat çeker: şifre çözme işlemlerinin çoğu yedek alınırken değil hazırlanırken yapıldığı için yanlış anahtar gibi sorunlar ancak --prepare sırasında ortaya çıkabilir.

Geri yüklemek (--copy-back ve --move-back)

Hazırlanmış tam yedek artık çalışan bir MariaDB veri dizinidir. Geri yükleme için belgelerdeki sıra şöyledir: önce MariaDB sunucusunu durdurun, veri dizininin boş olduğundan emin olun, ardından --copy-back ya da --move-back çalıştırın. --copy-back yedek dosyalarını korur, --move-back onları veri dizinine taşır ve yedek dizini boşalır. Dolu bir veri dizininin üzerine yazmak için --force-non-empty-directories seçeneği vardır, ama bu bilinçli yapılması gereken bir şeydir.

systemctl stop mariadb
mariadb-backup --copy-back \
   --target-dir=/var/mariadb/backup/
chown -R mysql:mysql /var/lib/mysql/
systemctl start mariadb

chown adımı neden var? Araç dosya izinlerini korur ama dosyaları, geri yüklemeyi çalıştıran kullanıcı ve grup adına yazar. root ile geri yüklediyseniz dosyalar root'a ait olur ve sunucu açılamaz. Belgeler sahibi genellikle mysql olan sunucu kullanıcısına geri vermenizi önerir. Veri dizini yolu dağıtıma ve yapılandırmanıza göre değişebilir; /var/lib/mysql/ belgelerdeki örnektir. Hazırlanmış yedek sıradan bir dizin olduğu için sunucu durduğu sürece rsync gibi bir araçla da kopyalanabilir. Servisi durdurup başlatma ayrıntıları systemd ile başlatma ve durdurma yazısında.

Artımlı yedek

InnoDB sayfaları bir günlük sıra numarası (LSN) taşır ve her satır değişikliğinde bu sayı artar. Artımlı yedekte araç, önceki yedeğin son LSN'sini veritabanındaki sayfalarla karşılaştırır ve yalnızca geride kalan sayfaları kopyalar. Bu özellik belgelere göre yalnızca InnoDB için vardır; diğer motorlar tam yedekle alınır. Artımlı yedek tek başına geri yüklenemez, her zaman bir tam yedeğe uygulanır.

Önce bir tam yedek alınır. Belgelerdeki örnekte tam yedeğin mariadb_backup_checkpoints dosyası şöyledir:

backup_type = full-backuped
from_lsn = 0
to_lsn = 1635102
last_lsn = 1635102
recover_binlog_info = 0

Ardından --incremental-basedir ile bu tam yedeğe göre değişiklikler ayrı ve boş bir dizine alınır. Bir sonraki artımlı yedekte taban olarak bir önceki artımlı yedeğin dizini verilir; böylece bir zincir oluşur.

mariadb-backup --backup \
   --target-dir=/var/mariadb/inc1/ \
   --incremental-basedir=/var/mariadb/backup/ \
   --user=mariadb-backup --password=mypassword

mariadb-backup --backup \
   --target-dir=/var/mariadb/inc2/ \
   --incremental-basedir=/var/mariadb/inc1/ \
   --user=mariadb-backup --password=mypassword

Belgelerde ilk artımlı yedeğin kontrol dosyası, from_lsn değerinin tam yedeğin to_lsn değeriyle aynı olduğunu gösterir:

backup_type = incremental
from_lsn = 1635102
to_lsn = 1635114
last_lsn = 1635114
recover_binlog_info = 0

Hazırlama sırası önemlidir. Önce taban tam yedek tek başına hazırlanır, ardından her artımlı yedek --incremental-dir ile sırayla tabana uygulanır. Sonunda geri yüklenen dizin her zaman taban tam yedeğin dizinidir; artımlı dizinler yalnızca değişiklik taşır.

mariadb-backup --prepare \
   --target-dir=/var/mariadb/backup
mariadb-backup --prepare \
   --target-dir=/var/mariadb/backup \
   --incremental-dir=/var/mariadb/inc1
mariadb-backup --prepare \
   --target-dir=/var/mariadb/backup \
   --incremental-dir=/var/mariadb/inc2

Dizin yollarıyla uğraşmak istemezseniz yedek geçmişi tablosunu kullanabilirsiniz. --history=ad ile alınan her yedek veritabanına kaydedilir; sonraki artımlı yedekte taban --incremental-history-name=ad ile adıyla gösterilir. MariaDB 10.11 ve sonrasında bu tablo mysql.mariadb_backup_history'dir ve InnoDB kullanır; daha eski sürümlerde CSV motorlu PERCONA_SCHEMA.xtrabackup_history tablosudur. Yedek kullanıcısının bu tabloda SELECT, INSERT, CREATE ve ALTER yetkisine ihtiyacı vardır; yetki yoksa belgelere göre dosya kopyası tamamlanır ama son adım INSERT command denied hatasıyla başarısız olur.

GRANT SELECT, INSERT, CREATE, ALTER ON mysql.mariadb_backup_history TO 'mariadb-backup'@'localhost';

Akış, sıkıştırma ve şifreleme

--stream=xbstream seçeneği yedeği dizine yazmak yerine standart çıktıya akıtır; böylece gzip, zstd, openssl veya gpg gibi araçlara borulayabilirsiniz. Akışı açmak için mbstream -x kullanılır. Belgelerdeki iki örnek aşağıda: ilki yalnızca sıkıştırır, ikincisi sıkıştırıp AES ile şifreler.

mariadb-backup --user=root --backup --stream=xbstream | gzip > backupstream.gz
gunzip -c backupstream.gz | mbstream -x

mariadb-backup --user=root --backup --stream=xbstream | gzip | openssl  enc -aes-256-cbc -k mypass > backup.xb.gz.enc
openssl  enc -d -aes-256-cbc -k mypass -in backup.xb.gz.enc |gzip -d| mbstream -x

Aracın kendi --compress seçeneği ise bakımı bırakılmış QuickLZ kütüphanesine dayandığı için kullanımdan kaldırılmıştır; belgeler onun yerine yukarıdaki gibi akışı dış bir sıkıştırma aracına vermeyi önerir. Akışla artımlı yedek almak isterseniz bir ayrıntıya dikkat edin: kontrol dosyası da sıkıştırılmış akışın içine girer ve bir sonraki artımlı yedek onu okuyamaz. --extra-lsndir bu dosyanın bir kopyasını ayrı bir dizine yazar; sonraki yedekte --incremental-basedir olarak o dizini verirsiniz.

mariadb-backup --backup --stream=mbstream \
  --user=mariadb-backup --password=mypassword \
  --extra-lsndir=backup_base | gzip > backup_base.gz

mariadb-backup --backup --stream=mbstream \
  --incremental-basedir=backup_base \
  --user=mariadb-backup --password=mypassword \
  --extra-lsndir=backup_inc1 | gzip > backup-inc1.gz

Bu son örnek belgelerin artımlı yedek sayfasından alınmıştır ve orada akış biçimi mbstream olarak yazılmıştır; seçenekler sayfası ise desteklenen biçimi xbstream olarak verir. Kendi betiğinizde seçenekler sayfasındaki --stream=xbstream yazımını tercih etmeniz daha güvenlidir.

Kısmi yedek ve sınırları

Belirli veritabanlarını veya tabloları almak için --databases, --databases-exclude, --tables, --tables-exclude ve dosyadan okuyan --databases-file, --tables-file seçenekleri vardır; dosya almayanlar düzenli ifade kabul eder. Ancak belgeler kısmi yedeğin bazı sınırlarını açıkça belirtir: tablo InnoDB'nin tablo başına dosya (file-per-table) alanında olmalıdır, bölümlenmiş bir tablonun yalnızca bazı bölümleri alınamaz, kısmi yedek artımlı yedek geçmişinin tabanı olamaz ve hazırlamada --export gerekir.

En önemli fark geri yüklemededir. Kısmi yedek eksiksiz bir veri dizini değildir; InnoDB sistem tablo alanında yedeğe girmeyen tabloların kayıtları da durur. Bu yüzden --copy-back kullanılamaz; her tablo dosyası çalışan bir sunucuya tek tek içe aktarılır. Tek bir tabloyu geri almak sık ihtiyaçsa, bunu mariadb-dump ile almak çoğu zaman daha pratiktir.

Canlı sistemde kilitler ve ince ayar

Varsayılan olarak araç tutarlı nokta için kısa bir FLUSH TABLES WITH READ LOCK alır. Uzun süren bir sorgu bu kilidi bekletebilir. --kill-long-queries-timeout=10 gibi bir değerle araç, belirtilen saniye sonunda kilidi engelleyen sorguları sonlandırır; varsayılan 0'dır, yani hiçbir sorgu öldürülmez. --kill-long-query-type hangi tür sorguların öldürülebileceğini (ALL, UPDATE, SELECT) belirler. Sorguları izleme ve öldürme konusu SHOW PROCESSLIST ve KILL yazısında.

--no-lock genel kilidi tamamen kapatır, ama belgeler bunu dar koşullara bağlar: yedek sırasında InnoDB dışındaki tablolara (MyISAM kullanan mysql sistem tabloları dahil) yazılmamalı, hiç DDL çalışmamalı, bütün tablolar InnoDB olmalı ve binary log konumu için mariadb_backup_binlog_info değil mariadb_backup_binlog_pos_innodb dosyası kullanılmalıdır. Replikada kilit alınamıyorsa belgeler --no-lock yerine replika SQL iş parçacığını geçici olarak durduran --safe-slave-backup seçeneğini önerir.

--parallel veri dosyalarının kaç iş parçacığıyla kopyalanacağını belirler; varsayılanı 1'dir. Çok sayıda tablo içeren sunucularda 'Too many open files' hatası görülebilir; belgeler bunun için --open-files-limit değerini artırmayı ya da aracı çalıştıran kullanıcının /etc/security/limits.conf içindeki dosya sınırlarını yükseltmeyi önerir.

[mariadb-backup]
open_files_limit=65535

Binary log konumu ve zamana göre kurtarma

Sunucuda binary log açıksa yedek, hangi binlog noktasına karşılık geldiğini mariadb_backup_binlog_info dosyasına yazar. Belgelerdeki örnek içerik dosya adı, konum ve gtid_current_pos değerinden oluşur:

mariadb-bin.000096 568 0-1-2

Zamana göre kurtarmada önce yedek geri yüklenir, ardından bu noktadan sonraki binary log olayları mariadb-binlog ile istenen ana kadar uygulanır. Bu dosyadaki değerler, belgelere göre yalnızca yedek --no-lock olmadan alındıysa yedekle tutarlıdır. Adımların tamamı binary log ve PITR yazısında; yedekten replika kurmak ise replikasyon kurulumu yazısında anlatılıyor.

MariaDB 12.3 ile gelen ve varsayılan olmayan InnoDB tabanlı binary log (binlog_storage_engine=innodb) bu tabloyu biraz değiştirir. Belgelere göre bu kipte binary log dosyaları varsayılan olarak yedeğe, diğer InnoDB verileriyle aynı tutarlılıkla dahil edilir; yer kazanmak için --skip-binlog ile dışarıda bırakılabilir. Geri yüklenen yedek, CHANGE MASTER içinde MASTER_DEMOTE_TO_SLAVE=1 ile yedeğin alındığı noktadan replika olarak başlatılabilir.

Uygulamalı örnek: haftalık tam, günlük artımlı

Pazar günü tam yedek, diğer günler artımlı yedek alan basit bir düzen düşünelim. Kimlik bilgileri [mariadb-backup] grubunda olduğu için komutlarda kullanıcı yazmıyoruz. Pazar günü tam yedek, pazartesi bu yedeğe göre, salı da pazartesiye göre artımlı yedek alınır:

mariadb-backup --backup --target-dir=/yedek/pazar
mariadb-backup --backup --target-dir=/yedek/pazartesi --incremental-basedir=/yedek/pazar
mariadb-backup --backup --target-dir=/yedek/sali --incremental-basedir=/yedek/pazartesi

Çarşamba sabahı salı akşamki duruma dönmeniz gerekirse, zinciri bozmamak için hazırlamayı yedeklerin kopyası üzerinde yapmak iyi bir alışkanlıktır; çünkü hazırlama taban dizini değiştirir. Sıra şudur: pazar hazırlanır, pazartesi uygulanır, salı uygulanır, sunucu durdurulur, veri dizini boşaltılır, --copy-back çalıştırılır, sahiplik düzeltilir ve sunucu başlatılır.

mariadb-backup --prepare --target-dir=/yedek/pazar
mariadb-backup --prepare --target-dir=/yedek/pazar --incremental-dir=/yedek/pazartesi
mariadb-backup --prepare --target-dir=/yedek/pazar --incremental-dir=/yedek/sali

Sık yapılan hatalar

• --prepare adımını atlamak: Hazırlanmamış dosyalar tek bir ana göre tutarlı değildir; InnoDB bunları açarken çöker.
• Dolu veri dizinine geri yüklemek: --copy-back ve --move-back boş bir veri dizini bekler ve sunucunun durdurulmuş olmasını gerektirir.
• Dosya sahipliğini düzeltmemek: Geri yüklemeyi root ile yaptıysanız dosyaları mysql kullanıcısına geri verin; aksi hâlde sunucu açılmayabilir.
• Artımlı yedekleri yanlış sırayla uygulamak: Önce taban, sonra artımlılar oluştukları sırayla uygulanır; her birinde hedef dizin tabandır.
• Uyumsuz araç sürümü kullanmak: Yükseltme öncesinde yedeği ve hazırlamayı, yedeği aldığınız sunucu sürümüyle uyumlu araçla yapın.
• Akışlı artımlı yedekte --extra-lsndir unutmak: Kontrol dosyası sıkıştırılmış akışın içinde kalır ve sonraki artımlı yedek tabanı bulamaz.
• --no-lock'u gelişigüzel kullanmak: MyISAM sistem tablolarına yazma ya da DDL varsa yedek tutarsız olur.

Sık Sorulan Sorular

mariabackup ile mariadb-backup farklı mı?

Hayır, mariabackup aracın eski adıdır. Belgeler yeni adı kullanır; komutlar ve seçenekler aynıdır.

Yedek sırasında uygulama durur mu?

InnoDB tabloları kopyalanırken uygulama çalışmaya devam eder. Sonda kısa bir FLUSH TABLES WITH READ LOCK alınır; bu sırada yazmalar kısa süre bekleyebilir. Uzun sorgular bu kilidi geciktiriyorsa --kill-long-queries-timeout seçeneğine bakın.

Tek bir tabloyu fiziksel yedekten geri alabilir miyim?

Mümkün, ama tam yedekteki gibi --copy-back ile değil. Hazırlamada --export kullanılır ve tablo dosyası çalışan sunucuya içe aktarılır. Belgeler bunun birden çok adım gerektirdiğini belirtir; sık tablo bazlı geri dönüş ihtiyacınız varsa ek olarak mantıksal yedek almak işinizi kolaylaştırır.

Sıkıştırma için --compress kullanmalı mıyım?

Hayır. Belgeler --compress seçeneğini kullanımdan kaldırılmış olarak işaretler ve yedeği --stream=xbstream ile akıtıp gzip veya zstd gibi dış bir araçla sıkıştırmayı önerir.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MariaDB öğrenme rehberi · mariadb-dump ile yedekleme · Binary log ve PITR · Replikasyon kurulumu · systemd ile başlatma ve durdurma · Yedekleme stratejileri