MySQL veya MariaDB yedeğinin amacı yalnız dosya üretmek değil, veriyi kabul edilebilir kayıp ve sürede geri getirmektir. Yanlış bir tablo silme işleminde gece yedeği yeterli olmayabilir; gün içindeki doğru işlemleri de kurtarmak için tutarlı bir başlangıç yedeği ve ona bağlı günlük zinciri gerekir. Bu rehber mantıksal yedek, fiziksel sıcak yedek ve zaman noktasına kurtarmanın hangi koşullarda kullanılacağını açıklar.
mysqldump şema ve veriyi yeniden çalıştırılabilir SQL olarak dışa aktarır. XtraBackup ve MariaDB için mariadb-backup (eski adı Mariabackup) fiziksel dosyaları ve gerekli kurtarma bilgilerini kopyalar. Point-in-Time Recovery (PITR) ise uygun bir yedeği geri yükledikten sonra binary log kayıtlarını belirlenmiş işlem sınırına kadar uygular. Araç seçimi veri hacmi kadar geri yükleme süresi, sürüm uyumu ve ekibin prova ettiği işletim adımlarına bağlıdır.
Yedek dediğin sadece dosya değildir: Önce neyi koruduğunu bil
Bazı takımlarda yedek, otomatik bir görev planlayıcının haftalardır sessizce çalıştırdığı bir komut dosyasından ibaret görünüyor. Ama yedek dediğin, aslında geceleri rahat uyumanı sağlayan bir hikâye. İçinde tutarlılık, geri dönüş planı, erişim izinleri ve hatta paniğe kapılmadan atacağın adımlar var. Mesela şöyle düşün: küçük bir blog için gece alınan tek bir tam yedek belki uzun süre işini görür. Ama canlı sipariş alan bir e‑ticaret sitesinde aynı yaklaşım, öğlen saatlerinde yanlış bir güncelleme yapıldığında seni eski güne hapseder. Bu yüzden yedeğin dosya değil, bir strateji olduğunu akılda tutmak gerekiyor.
Bir başka açıdan bakalım. Yedekleme bir sigorta poliçesine benzer, ama poliçeyi okuduğunu varsayarsın. Oysa gerçek hayatta, geri dönüşü denemeden hiçbir yedek tamam değildir. Yedek almayı çözmek kadar, onu geri dönmeyi prova etmek de gerekir. Zaman zaman bir test sunucusu kurup geriye dönmeyi, indirdiğin dosyanın gerçekten açıldığını ve tablolardaki verinin beklediğin gibi olduğunu görmek, gecenin bir vakti alınacak en güzel nefes olur. Bu arada, uzak lokasyonda saklama, çoklu kopya ve otomasyon gibi pratikleri tek bir çatı altında anlatan şu yazıya göz atmak fena olmaz: 3‑2‑1 yedekleme stratejisi ve otomatik yedekler üzerine sıcak bir rehber.
mysqldump ile mantıksal yedek: Basit, güvenilir, ama sabırlı olmalı
mysqldump, şema ve veriyi SQL biçiminde dışa aktarır; MariaDB ortamında dağıtımın desteklediği mariadb-dump istemcisini kullanın. Mantıksal dosya okunabilir ve taşımaya elverişlidir, fakat farklı sürümler arasında SQL, karakter seti, collation ve özellik uyumu ayrıca doğrulanmalıdır. Bir veritabanı dump’ı sunucudaki bütün kullanıcıları, yetkileri ve dış bağımlılıkları kendiliğinden kapsamaz. Şema değişikliklerini yedekleme penceresiyle koordine edin.
InnoDB tablolarında --single-transaction, dump boyunca tutarlı bir işlem görüntüsü sağlar; MyISAM/MEMORY gibi işlemsel olmayan tablolara aynı güvenceyi vermez. Yedek sırasında ilgili tablolarda ALTER, CREATE, DROP, RENAME veya TRUNCATE gibi DDL işlemleri yapılmamalıdır. --routines --triggers --events --hex-blob --default-character-set=utf8mb4 bir seçenek listesidir, tek başına çalışır komut değildir: doğru istemci, bağlantı, yetkiler, veritabanı seçimi ve korumalı çıktı hedefi eklenmelidir. PITR koordinatı alma seçenekleri başlangıçta kısa bir kilit gerektirebilir; “tek oturum” sıfır kilit veya sıfır yük demek değildir.
Geri yükleme, SQL ifadelerini ve indeksleri yeniden oluşturduğu için doğru seçeneklerle bile uzun sürebilir. Yedek alma ve geri dönme sürelerini ayrı ölçün. Replikadan yedek alıyorsanız gecikmesini ve kaydedilen koordinatların hangi sunucuyu temsil ettiğini doğrulayın. Tabloları gelişigüzel dilimlemek ortak bir tutarlı görüntü üretmez; ilişkili veriler için koordineli snapshot gerekir. Sıkıştırma hattında yalnız son programın değil dump ve aktarım adımlarının da çıkış durumunu izleyin.
XtraBackup ve Mariabackup ile sıcak yedek
XtraBackup ve mariadb-backup, desteklenen motor ve sürümlerde sunucu çalışırken fiziksel yedek alabilir. Veri dosyaları farklı anlarda kopyalandığından redo kayıtları ve hazırlık aşaması tutarlılık için gereklidir. Sıcak yedek, yük yaratmayan veya hiçbir koşulda kilit almayan yedek anlamına gelmez: disk okuması, CPU, DDL ve işlemsel olmayan tablolar için gereken kilitler üretimi etkileyebilir. Yedek penceresini gerçek trafik altında ölçün.
Artımlı yedek, bağlı olduğu tam yedek ve önceki artımlar olmadan kullanılamaz. LSN zincirini ve bütün ara dosyaları koruyun; artımları doğru sırayla uygulayın. XtraBackup’ta ara prepare aşamalarında rollback’i ertelemek gerekir; erken sonlandırma daha sonraki artımları uygulamayı engelleyebilir. Sürüme ait Percona XtraBackup belgeleri ile adımları eşleştirin. Hazırlanmış kopyayı, durdurulmuş izole hedefin boş veri dizinine geri yükleyin; doğru izinler, yapılandırma ve şifreleme anahtarları olmadan sunucuyu başlatmayın. Çalışan üretim dizininin üstüne dosya kopyalamayın.
MySQL/Percona Server için XtraBackup’ın destek matrisini, MariaDB için sunucuya uyumlu mariadb-backup sürümünü seçin. Bu araçlar veya fiziksel dosyalar MySQL ile MariaDB arasında serbestçe değiştirilemez. MariaDB Backup belgeleri ürünün hazırlık ve geri yükleme adımlarını açıklar. Veri büyüdüğünde fiziksel yöntem yararlı olabilir; avantajı ancak yük ve tam kurtarma süresi ölçüldüğünde doğrulanır.
Point‑in‑Time Recovery: Yanlış bir adımı, saate bakarak geri almak
Varsayımsal olarak 09:00 yedeğinden sonra 12:37’de hatalı bir silme yapıldığını düşünün. PITR, tutarlı 09:00 yedeğinin kaydettiği başlangıç koordinatından itibaren korunmuş binary log zincirini işler. Hatalı işlemin öncesindeki doğru olay/transaction sınırında durmak gerekir. 12:36:59 gibi yaklaşık bir saat, aynı saniyedeki işlemleri ayırmayabilir; bir saniye önceye dönmek her doğru işlemi koruma garantisi vermez.
PITR için binary logging olaydan önce etkin olmalı, gerekli değişiklikleri kapsamalı ve günlükler yedeğin koordinatından hedef noktaya kadar kesintisiz saklanmalıdır. MySQL 8.0.26 ve sonrasında mysqldump için --source-data=2 koordinatları yorum satırı olarak ekler; eski sürümlerdeki karşılığı --master-data=2 seçeneğidir. MariaDB’de kendi istemci ve sürüm belgelerine göre koordinat seçeneğini belirleyin. Fiziksel araçların ürettiği koordinat dosyalarını da yedeğin parçası olarak saklayın. MySQL PITR rehberi başlangıç yedeği ile günlüklerin birlikte kullanılmasını anlatır.
Zaman bilgisi, loglarda hatalı olayı bulmak için başlangıçtır. mysqlbinlog zaman filtreleri çalıştırıldığı makinenin yerel saat dilimine göre yorumlanır; olay sınırını inceleyip durma konumunu kaydedin. Gelişigüzel bir dakikalık tampon, geçerli siparişleri de dışarıda bırakabilir. Yedekten ayrı ve izole bir hedefte geri yükleme/replay yapın. Replay işlemlerinin hedefte yeniden binary log’a yazılıp yazılmayacağını replikasyon ve devreye alma planına göre belirleyin; gerekli oturum ayarını gerçek replay bağlantısında uygulayın. Başka bir bağlantıdaki ayar replay oturumunu değiştirmez. Hedef noktadan sonraki doğru yazmalar, ödeme sağlayıcısındaki işlemler ve kuyruklar otomatik geri gelmez; yeniden devreye almadan önce bunları uzlaştırın.
Gerçek hayatta strateji kurmak: Küçük blog mu, yoğun mağaza mı?
Az değişen bir blogda, kabul edilen veri kaybı ve geri yükleme süresini karşılıyorsa günlük mantıksal yedek yeterli olabilir. Daha dar bir veri kaybı hedefi için koordinatları kayıtlı yedek ve sürekli korunan binary log zinciri gerekir. Günlüklerin yalnız kaynak diskte bulunması sunucu kaybında işe yaramayabilir; ayrı konuma aktarım gecikmesini de ölçün. Taşınabilirlik faydalıdır, ancak hedef sürümde geri yükleme provası yine gereklidir.
Yoğun mağazada fiziksel tam ve artımlı yedekler, veri hacmine göre mantıksal dışa aktarmaya alternatif olabilir. Takvimi yazma hızı, disk kapasitesi ve restore ölçümlerine göre kurun; sıcak yedek veya PITR kesintisizlik garantisi değildir. Ürün, sipariş, ödeme ve şema değişikliklerinin tutarlılığını test edin. Veritabanı yedeğiyle birlikte uygulama sürümü, medya/dosya yedekleri ve dış sistemlere bağımlılıkları da kurtarma planına bağlayın.
RPO, kabul edilen veri kaybı aralığı; RTO, hizmeti geri getirmek için hedeflenen süredir. RPO’yu yedek sıklığı kadar günlüklerin güvenli konuma ulaşma gecikmesi belirler. RTO’ya indirme, şifre çözme, açma, prepare, günlük oynatma, uygulama doğrulaması ve trafiği devretme dahildir. Sık artımlı yedek depolamayı azaltabilir ama zinciri uzatarak kurtarmayı karmaşıklaştırabilir; seçimi tam bir provayla doğrulayın.
Geri dönüş provası, küçük nüanslar ve sık yapılan hatalar
İşin en çok atlanan yeri, prova. Bir test sunucusu açıp, elindeki yedeği geri dönmek ve uygulamanın çalıştığını görmek kadar rahatlatan az şey var. Test uygulamasının gerçek ödeme, e-posta ve arka plan işlerini tetiklemesini engelleyin; bu bağlantıları kapatın veya güvenli test hedeflerine yönlendirin. Dosyalar sağlam mı, karakter setleri yerli yerinde mi, tablolar ve ilişkiler beklediğin gibi mi, hepsini bu provada görürsün. Mantıksal yedekte, prosedürler, tetikleyiciler ve zamanlanmış görevler için uygun bayrakları eklemeyi unutmamak gerekir; aksi halde geri dönüşte bir şeylerin eksik olduğunu fark etmek moral bozabilir. Fiziksel yedekte ise hazırlık adımını (apply/prepare) atlamamak, dosyaların tutarlılığını sağlamanın anahtarıdır.
Veritabanı kullanıcıları, roller, yetkiler ve DEFINER bağımlılıklarını ayrıca envanterleyin. Uygulama veritabanının dump’ı bunların tümünü kapsamayabilir; sürüme uygun dışa aktarma veya yeniden oluşturma adımlarını kaydedin. Fiziksel yedekte de dış yapılandırma, TLS malzemesi, keyring ve uygulama sırları için ayrı kurtarma planı gerekebilir. Restore hesabına gerekli yetkileri verin, günlük uygulamasının ve uygulama kullanıcısının gerçekten çalıştığını prova edin.
Fiziksel yedekte “yakın sürüm” yeterli bir uyumluluk ölçütü değildir. Sunucu sürümü, backup aracı, sayfa boyutu, şifreleme ve dosya düzeni ürünün destek matrisiyle uyumlu olmalıdır. Sürüm denetimini atlayarak kopyayı zorla açmayın. Önce desteklenen sürüme geri yükleyip üreticinin geçiş yolunu izleyin; mantıksal aktarım veya replikasyon da her sürüm çifti arasında otomatik olarak desteklenmez.
Günlük saklama süresi, dönmek istediğiniz en eski kullanılabilir yedeğin koordinatından hedef ana kadar zinciri korumalıdır. Yedi günlük yedek tutup yalnız üç günlük binlog saklamak eski yedeklerden PITR yapma imkânını sınırlar. Aktarım başarısını, dosya sırasını ve boşlukları izleyin; yalnız disk doluluk oranına göre otomatik silmeyin. Artımlı yedeklerin dayandığı tam yedek ve ara parçaları da aynı bağımlılık hesabıyla saklayın.
mysqldump ve XtraBackup’ı aynı mutfakta buluşturmak
Mantıksal ve fiziksel yedekler birlikte kullanılabilir: biri seçili veri aktarımı ve okunabilirlik, diğeri hacimli veri için farklı bir geri yükleme yolu sağlar. Örneğin fiziksel tam/artımlı zincir yanında dönemsel mantıksal dışa aktarım planlanabilir; iki işin toplam yükünü ölçün. PITR her başlangıç yedeğinin doğru koordinatı ve kesintisiz binloglarıyla kurulmalıdır. Yalnız günlükleri açmak veya iki farklı yedek dosyası üretmek kurtarma garantisi değildir.
Varsayımsal bir projede tam fiziksel yedek, ona bağlı artımlılar ve ayrı mantıksal dışa aktarımlar tutulabilir. Toplu güncelleme hatasında doğru fiziksel zincir hazırlanıp günlükler seçilen sınırda durdurulur. Bir analiz için tek tablo gerektiğinde mantıksal kopya daha kullanışlı olabilir. Ancak tablonun başka tablolarla ilişkisi ve verinin hangi ana ait olduğu kontrol edilmelidir; farklı tarihli kopyaları gelişigüzel birleştirmek tutarlılık sağlamaz.
Otomasyon, bildirim ve küçük konforlar
Zamanlayıcıyı yalnız çalıştığı için başarılı saymayın. Dump, sıkıştırma, şifreleme ve aktarım adımlarının çıkış kodlarını; beklenen nesneleri, boyut değişimini, checksum’u ve yedek yaşını izleyin. Hata ve gecikme için sorumlu kişiye ulaşan bildirim kurun. Checksum dosyanın aktarımda değişmediğini gösterebilir; SQL’in yüklenebilir veya verinin tutarlı olduğunu kanıtlamaz. Bunun için periyodik gerçek restore gerekir.
Yedekleri aktarımda ve depoda şifreleyin, erişimi sınırlayın ve kaynak sunucudan bağımsız kopya tutun. Araçların şifreleme desteği aynı değildir: mariadb-backup akışı harici şifreleme/sıkıştırma araçlarıyla işlenebilir; XtraBackup seçeneklerini kendi sürümünde doğrulayın. Anahtarları yedekle aynı tek arıza noktasına bırakmayın. Anahtar rotasyonunda saklanan eski yedekleri açmak için gereken anahtarları da koruyun ve erişilebilirliğini test edin.
Test senaryosu yazmak ve ekibe anlatmak
Kurtarma akışına seçilecek yedek zincirini, koordinatları, saat dilimini, durma sınırını, uyumlu hedef sürümünü ve gerekli anahtarları yazın. İzole hedefi hazırlama, geri yükleme, günlük uygulama ve uygulama kontrolünü sıraya koyun. Ardından daha sonraki geçerli sipariş/ödeme olaylarını uzlaştırma, trafiği devretme ve sorun çıkarsa geri çekilme adımlarını tanımlayın. Ekipten başka bir kişinin bu kayıtlarla prova yapabilmesi, belgenin kullanılabilirliğini gösterir.
Bu tür akışları anlatırken benzer konulara da denk geliriz. Mesela içerik dağıtımı yapan sitelerde, önbellek katmanı ve kenar ayarları olayı hızla etkiler. Yedekten dönünce önbelleği boşaltmak mı gerekir, yoksa belirli sayfaları güncellemek mi? Bu tip yan soruları da akışın sonlarına küçük notlarla eklemek, geri dönüşün ardından “her şey yolunda mı” sorusunu hızlı cevaplamana yardım eder.
Kurtarma planını ölçerek doğrulayın
mysqldump taşınabilir mantıksal yedek sağlar; fiziksel araçlar uyumlu sürümlerde farklı hız ve kaynak dengeleri sunar. Hiçbiri sıfır yük veya sabit kurtarma süresi vaat etmez. PITR, doğrulanmış başlangıç yedeği ve günlük zinciriyle seçilen işlem sınırına dönmeyi sağlar; sonrasındaki verilerin uzlaştırılması ayrı iştir. İyi planın kanıtı dosyanın varlığı değil, ölçülmüş ve doğrulanmış kurtarmadır.
İşe RPO/RTO hedefleri, nesne envanteri ve bir izole restore provasıyla başlayın. Sonuca göre yedek/günlük sıklığını, saklama kapasitesini ve bildirimleri ayarlayın. Provaları değişiklik hızına ve hizmetin önemine göre düzenli tekrarlayın; aylık bir kontrol bazı sistemlerde başlangıç olabilir, kritik sistemlerde daha sık doğrulama gerekebilir. Şifreleri, anahtarları, dış bağımlılıkları ve ekip sorumluluklarını aynı plana dahil edin.
