MySQL/MariaDB Yedekleme Stratejileri: mysqldump mı, XtraBackup mı ve Point‑in‑Time Recovery Ne Zaman?

Bir sabah, kahvemi alıp sunucu ekranına baktığımda şunu gördüm: veritabanı boyutu gece sessizce büyümüş, sorgular da daha ağır çalışıyor. O an, aklıma aynı ekibin önceki haftalarda yaşadığı talihsiz bir tablo silme olayı geldi. Kendi kendime, yedeklerin varlığı kadar nasıl alındığı ve nasıl geri dönüleceğinin de önemli olduğunu tekrar hatırladım. Bu yazıda sana, MySQL/MariaDB için yedekleme stratejilerini; sıcak ve anlaşılır bir dille, gündelik yaşadığımız hataları ve kurtuluş yollarını düşünerek anlatmak istiyorum. Hiç başına geldi mi, bir tabloyu yanlışlıkla silip saniyeler içinde geri almak istedin ama elindeki yedek sadece geceye ait olduğu için çaresiz kaldın?

İşte tam burada iki dosttan söz edeceğim: biri mantığı anlatan, her şeyi satırlara döken klasik yol; diğeri ise motorun içinden bir kopya çekip sistemi pek yormadan işini yapan çevik bir yol. İlki mysqldump. Diğeri XtraBackup (ve MariaDB tarafında Mariabackup). Bir de ikisinin üzerine kremayı süren, çoğu zaman günü kurtaran bir yöntem var: Point‑in‑Time Recovery, yani belirli bir zamana kadar geri dönme. Yazının sonunda, hangi senaryoda hangisinin gönlünü alman gerektiğini, pratik ipuçlarıyla beraber, gerçek hayatta işe yarayan bir strateji olarak cebine koymanı istiyorum.

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, veritabanını satır satır okur ve bunu tekrar içeri aktarabileceğin bir dosyaya döker. Bunu, bir kütüphanedeki tüm kitapların özetini yazıp güvenli bir çekmeceye koymak gibi düşünebilirsin. Küçük ve orta boy veritabanlarında, özellikle şema değişiklikleri sık oluyorsa ve tablo yapısını da beraberinde taşımak istiyorsan gerçekten pratik olur. Aktarması kolaydır; yeni bir ortama taşırken de rahat ettirir. Çünkü içeride ne varsa, metin dünyasında anlaşılır bir dile dönmüştür.

Bir örnekle akılda kalsın. InnoDB kullanan bir veritabanında servis kesmeden daha tutarlı bir mantıksal yedek almak için tek oturumluk bir yaklaşım iş görür. Pek çok kişinin işine yarayan bir komut şöyle bir gövdeye benzer: mysqldump –single-transaction –routines –triggers –events –hex-blob –default-character-set=utf8mb4. Burada hedef, yedeğin tutarlı olması ve döndüğünde sürpriz yaşamamaktır. Özellikle tek oturum kullanmak, işlem yapılan tablolarda kilitlenme yaşatmadan o anın tutarlı bir anlık görüntüsünü yazdırmana yardımcı olur. Elbette her ortamın küçük ayarları olur, ama iskelet bu yöndedir.

mysqldump ile geri dönmek de genelde rahattır. Dosyayı içeri okutursun, şema oluşur, veriler akar ve bir süre sonra sistem ayağa kalkar. Ama burada kabul etmemiz gereken bir gerçek var: dosya büyüdükçe, bu akış yavaşlar. Yedek alma süresi uzayabilir, geri dönüş de beklediğinden uzun sürebilir. Böyle zamanlarda, canlı trafiği çok etkiliyorsa pencere belirlemek, replikaya bağlanıp oradan almak veya dilimleyerek yedeklemek gibi küçük çözümler devreye girer. Yani mysqldump seni kolaylıktan yana mutlu eder, ama büyüdükçe sabır ister.

XtraBackup ve Mariabackup ile sıcak yedek: Sistem nefes alırken kopyayı almak

Bir de işin fiziksel tarafı var. XtraBackup (ve MariaDB dünyasında Mariabackup), veritabanını dosya seviyesinde kopyalar. Bu yaklaşım, çalışan motorun içinden geçip veri dosyalarını alırken, sistemi mümkün olduğunca kilitlemez. Canlı bir mağazada rafları sayarken müşterileri içeri almaya devam etmek gibidir; işler akarken arka tarafta sayım yapılır. Büyük verilerde, kısıtlı bakım pencerelerinde ve düşük gecikmenin kritik olduğu ortamlarda nefes aldırır.

Buradaki sihir, hazırlık adımlarında gizlidir. İlk alınan tam yedekten sonra artımlı yedeklerle arayı doldurmak mümkündür, böylece her seferinde tüm mağazayı baştan saymazsın. Yedekten geri dönerken, önce aldığın kopyayı hazırlarsın; üzerinde küçük bir düzeltme yapılır ve tutarlı hale getirilir. Bu hazırlık, geri dönüşe giden köprüdür. Sonra verileri hedef dizine yerleştirir, sunucuyu açarsın. Büyük verilerde bile, sistemin nefesini çok kesmeden bu yol rahatlatır. Hangi ana hatların geçerli olduğunu görmek istersen, Percona XtraBackup belgeleri kısa sürede yönünü bulmana yardım eder.

Şu ayrımı da akılda tutmak iyi olur. XtraBackup, MySQL ve Percona Server dünyasında doğal vatandaş gibidir. MariaDB tarafında ise benzer mantığı taşıyan Mariabackup kullanılır. İkisi de aynı aileden gelen, farklı mutfaklara uyarlanmış usuller gibi düşünülebilir. MariaDB’ye özel detayları merak edersen, MariaDB’nin Mariabackup sayfası seni bekliyor. Özetle, canlıda zorlama yaratmadan kopya almak istiyorsan ve veri boyutu büyüdüyse, bu sıcak yedek yaklaşımı gününü güzelleştirir. Ama ilk kez kullanıyorsan, küçük bir test ortamında prova yapmak moralini yükseltir.

Point‑in‑Time Recovery: Yanlış bir adımı, saate bakarak geri almak

Gelelim hepimizin içini ferahlatan, ama iş başa gelmeden pek kurulmaya yanaşmadığımız o güzel yönteme: Point‑in‑Time Recovery. Bunu gündelik bir örnekle anlatayım. Diyelim ki sabah 09:00’da eksiksiz bir tam yedeğin var. 12:37’de de bir arkadaşın, sipariş tablosunda istemeden bir silme yaptı. Eğer veritabanı değişikliklerini adım adım kaydeden günlükler (binary log) açıksa, 12:37’ye kadar olan tüm iyi hareketleri, 12:36:59’a dek çalınan bir kaset gibi geri oynatabilirsin. Bu sayede, sabahın huzurunu öğlene taşımış olursun.

Adımların ruhu basit. Önce günlük kaydının açık olduğundan emin olursun ki her değişim kayda geçsin. Sonra düzenli bir tam yedek alırsın; ister mysqldump ile mantıksal, ister XtraBackup/Mariabackup ile fiziksel. Bir sorun yaşandığında, önce o tam yedeği geri yüklersin. Ardından günlük dosyalarını sırayla işleyip belirlediğin zamana kadar olan değişiklikleri uygulayarak sistemi o ana getirirsin. Saat bilgisini ya da belirli bir işlem numarasını baz almak mümkün. Bu akışın ana hatları, MySQL rehberindeki zaman noktasına kadar kurtarma anlatımında da çok net durur.

Pratikte, saati ve olayı iyi yakalamak önemlidir. Olayın ne zaman gerçekleştiğini loglardan, uygulama hatalarından veya ekip arkadaşının attığı mesajdan öğrenirsin. Birkaç dakikalık tampon pay bırakmak çoğu zaman işe yarar; yani 12:37’de hata olduysa 12:36’ya kadar geri almak daha güvenlidir. Mantıksal yedekle geri dönüşte günlükleri oynatmak, dosyaları içeri okurken komutun ucuna ‘şu zamana kadar uygula’ demen gibidir. Fiziksel yedekte ise sistem ayağa kalktıktan sonra günlükleri betiklerle sıraya koyup uygularsın. İkisi de aynı fikri paylaşır: iyi olanı tut, hataya gelmeden dur.

Gerçek hayatta strateji kurmak: Küçük blog mu, yoğun mağaza mı?

Yedek stratejisini masa başında değil, ayağa kalkıp sistemi izlerken kurmak gerekir. Mesela küçük bir blogun varsa ve içerik günde bir iki kez değişiyorsa, gece alınan tek bir mantıksal tam yedek, üstüne de günlüklerin açık olması çoğu zaman yeter. Böylece bir yanlışlık olursa, sabah yedeğine döner, günlükleri hataya gelmeden önceki ana kadar uygularsın. Bu yaklaşım düşük maliyetli, basit ve anlaşılırdır. Hatta yeni bir sunucuya geçerken aynı dosyayı kullanarak taşımayı da kolaylaştırır.

Yoğun bir e‑ticaret mağazası için işin tadı biraz değişir. Canlı sistemde kapıya kilit vurmak istemezsin. Burada fiziksel tam yedekle işe başlamak, gün içinde artımlı yedeklerle devam etmek, günlükleri açık tutmak ve akşam saatlerinde kısa prova geri dönüşleri yapmak içi rahatlatır. Bu akışla, kapı hiç kapanmadan rafları sayarsın; hata olduğunda da elindeki günlükleri oynatarak en az veri kaybıyla günü kurtarırsın. Bazen sadece veri değil, şemanın değiştiği anlar da olur; versiyonlamayı ciddiye almak, yedekle beraber şema değişikliklerini takip etmek, ileride kafanı ağrıtmaz.

Bazı takımlar için geri dönüş süresi kadar, kaybedilebilecek veri miktarı da kritik bir ölçüdür. Basitçe söylemek gerekirse, sistemin ne kadar süre kapalı kalabileceğini ve en fazla ne kadar verinin kaybolmasına razı olduğunu netleştirmek gerekir. Bu iki cevabı aldıktan sonra plan netleşir. Kapanma süresi düşük, veri kaybı kabulü minimumsa, sıcak yedek ve sık artımlı kopyalarla günlüklerin gücünden yararlanırsın. Kapanma süresi sorun değilse, mantıksal yolun sadeliği ve taşınabilirliği seni mutlu eder.

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. 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.

Bir başka nüans, erişim izinleri ve kullanıcı hakları. Bazı ortamlarda kullanıcı ve yetkiler ayrı yerde saklanabilir ya da beklenmedik şekilde geri dönüşte çıplak kalabilir. Bu yüzden sık sık şunu yaparım: yedeğin içine bu bilgileri de dahil edecek küçük bir dokunuş eklerim, ya da en azından geri dönüş senaryosunda bu hakların nasıl yeniden tesis edileceğini not ederim. Geri dönüş betiklerinin başına küçük hatırlatmalar eklemek, panik anında büyük savunmadır.

Versiyon uyumu da sessiz ama etkili bir konu. Yedek aldığın sürümle geri döndüğün sürümün çok farklı olmaması işleri kolaylaştırır. Özellikle büyük sürüm geçişlerinde, önce test ortamında denemek ve yeni sürümün beklentilerini görmek, geri dönüşü akışkan hale getirir. MariaDB ve MySQL’in bazı konularda ayrı yollara gittiği anlar olabilir; bu yüzden belgelere bir göz atmak, boşlukları doldurur. Küçük notlar, büyük panikleri önler.

Günlüklerin saklama süresi de bir başka denge işidir. Çok kısa tutarsan, hataya kadar geri oynatma şansını kaybedebilirsin. Çok uzun tutarsan, depolama planın zorlanır. İyi bir orta yol bulmak için sistemin değişim hızına bakarım; yoğun sistemde daha sık artımla desteklerim ve günlük saklamayı birkaç adım geriden ama ulaşılabilir tutarım. Böylece felakete dönüşmeden önce çoğu hatayı, belirli bir zamana dönüp telafi etmek mümkün olur.

mysqldump ve XtraBackup’ı aynı mutfakta buluşturmak

Bazı ekipler, tek bir yönteme bağlanmak yerine ikisini birlikte kullanmayı tercih ediyor. Mantıksal yedek, taşınabilirlik ve okunabilirlik sağlarken; fiziksel yedek, canlıyı zorlamadan büyük verileri güvene alıyor. İkisini aynı takvimde buluşturduğunda, mesela haftada bir fiziksel tam yedek, aralara artımlılar ve her gece mantıksal bir paket koyduğunda, hem hızdan hem esneklikten pay almış olursun. Üzerine günlükleri açık tutmak da, zamana kadar geri dönüşü garantiler.

Burada küçük bir anımı paylaşayım. Bir projede, ayın ilk günü fiziksel tam yedek alıyorduk. Her gece mantıksal paket yaratıp arşivliyorduk. Gün boyunca artımlı fiziksel kopyalarla arayı dolduruyor, günlükleri de ayrı bir kasaya koyuyorduk. Bir gün öğleden sonra bir toplu güncelleme hatası oldu. Takvimdeki en yakın fiziksel kopyaya dönüp günlükleri oynatarak hatayı aştık; ama işin asıl hoş yanı, başka bir analizin gerektirdiği ufak bir tabloyu da mantıksal dosyadan hızlıca çekip çıkarmamız oldu. İki yöntemin bir arada çalışması, o gün bize hem hızı hem esnekliği verdi.

Otomasyon, bildirim ve küçük konforlar

Yedek çalışan bir maraton ise, otomasyon onun düzenli nefesidir. Zamanlanmış görevler, basit betikler ve küçük denetimler, her gün aynı ritmi tutturmana yardım eder. Ben çoğu zaman yedek işinin sonunda küçük bir kontrol yaptırırım: dosya boyutu makul mü, kontrol toplamı doğru mu, dizine düşen dosya sayısı beklenen kadar mı? Varsa bir sorun, bildirim kanalına kısa bir not düşer. Küçük bildirimler, büyük aksaklıkları büyümeden yakalar.

Şifreleme ve uzak kopya, göz ardı edilmemeli. Yedek, içindeki verinin mahremiyetini sırtında taşır. Depoya giderken ve depoda dururken şifreli olması, işin vicdanı gibidir. Uzak kopya ise tek seferde hepsini kaybetmeme sigortasıdır. Bir de ağ içinde sıkıştırma ve bant genişliği verimliliğini düşünmek, özellikle artımlı kopyalarda rahatlatıcı olur. Küçük ayarlar, günün sonunda büyük zaman kazandırır.

Test senaryosu yazmak ve ekibe anlatmak

Geri dönüş senaryosunun bir sayfalık kısa bir akış şeması, ekipte bir çarpan etkisi yaratır. Bir arkadaşın izindeyken de süreç aksamaz. Şöyle bir akış düşün: önce hangi yedeğe dönüleceği kararlaştırılır, ortam hazırlanır, yedek geri yüklenir, günlükler belirlenen ana kadar uygulanır ve uygulama üzerinden basit bir sağlık kontrolü yapılır. Bu akış adım adım yazılıp paylaşıldığında, paniği cebinden çıkarıp masanın üstüne koyarsın; herkes görür, herkes aynı sayfada olur.

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.

Kapanış: En iyi yedek, dün gece test ettiğin yedektir

Bu yolculuğu toplarken, aklımda tek bir cümle kalıyor: en iyi yedek, dün gece test ettiğin yedektir. mysqldump sana sadelik ve taşınabilirlik sunar; küçük ve orta boy verilerde hızlıca nefes aldırır. XtraBackup ve Mariabackup ise canlı sistemdeki yükü artırmadan büyük verileri güvenceye alır; artımlı yaklaşımla gün içinde sürekli güvende kalırsın. Üzerine Point‑in‑Time Recovery eklediğinde, hatayı saatine bakarak geri alırsın. Hepsini bir araya getirince, dosyaların değil, planın güvende olduğunu hissedersin.

Pratik önerilerle bitireyim. Günlükleri açık tut, düzenli tam yedek al, aralara artımlı kopyalar serpiştir, küçük bir test ortamında geri dönüşü ayda en az bir kez prova et. Yedekleri şifrele, uzak bir kasada sakla, bildirim ve kontrol adımları ekle. Ve en önemlisi, ekibe bu hikâyeyi anlat; çünkü bir akşam arandığında, telefondaki ses yalnız sen olmayabilirsin. Umarım bu yazı, yarın sabah kahveni biraz daha sakin yudumlamana yardım eder. Bir dahaki yazıda görüşmek üzere.