Veritabanı Yedekleme ve Kurtarma

Yedekleme stratejisi araçla değil, hedeflerle başlar #

Etkili bir yedekleme stratejisi, doğru aracı seçmekle değil, aşağıdaki iki kritik metriği belirlemekle başlar:

• RTO (Recovery Time Objective): Veritabanı erişilemez duruma geldiğinde sistemin ne kadar süre kapalı kalabileceğini, yani kabul edilebilir kesinti süresini tanımlar.
• RPO (Recovery Point Objective): Olası bir felaket senaryosunda maksimum ne kadarlık veri kaybının tolere edilebileceğini belirler.

RTO ve RPO hedeflerini teknik ekipler değil, iş birimleri belirler. Örneğin bir e-ticaret platformunda 15 dakikalık bir veri kaybı dahi kabul edilemezken, gecelik toplu işlem (batch processing) yürüten bir raporlama veritabanında bir günlük veri kaybı makul karşılanabilir. Aynı yedekleme araçları kullanılsa bile, iki senaryo için tamamen farklı mimariler tasarlanır.

Sahada en sık karşılaştığımız sorun, RTO ve RPO hedeflerinin hiç belirlenmemiş olmasıdır. Çoğu sistemde her gece standart tam yedek (full backup) alınır; ancak bir kesinti anında sistemin ne kadar sürede ayağa kalkacağını kimse bilmez. Bu bilgi genellikle ilk büyük kesintide, en kötü anda ortaya çıkar.

MySQL çözümleri #

Fiziksel (physical) yedekleme süreçlerinde Percona XtraBackup kullanıyoruz. Araç, çalışan sunucuyu kilitlemeden tam yedek almamızı sağlar. Artımlı yedeklemelerde, referans alınan temel yedeğe göre iki farklı strateji kurgulanabilir:

• Differential (fark): Her yedek, son alınan tam yedeğe göre oluşan değişiklikleri içerir. Daha fazla disk alanı tüketir; buna karşılık geri yükleme (restore) işlemi belirgin şekilde hızlanır.
• Incremental (artımlı): Her yedek, bir önceki yedeğe göre oluşan değişiklikleri içerir. Disk alanından tasarruf sağlar; ancak geri yükleme aşamasında yedek zincirinin eksiksiz olması gerekir.

Hangi stratejinin seçileceği tamamen hedeflenen RTO süresine bağlıdır. Tek bir tabloyu kurtarmak veya sürümler arası veri göçü (migration) yapmak gibi mantıksal (logical) yedekleme ihtiyaçlarında ise mysqldump, büyük veri setlerinde paralel işlem yapabilen mydumper devreye girer.

Belirli bir anı kurtarmak amacıyla, PITR (Point-in-Time Recovery) stratejisi kapsamında binary log (binlog) arşivlemesi yapılandırıyoruz. Alınan son yedek gece 03:00’e ait olsa bile, binlog kayıtları sayesinde saat 14:37’de çalıştırılan hatalı bir UPDATE sorgusunun hemen öncesine dönmek mümkündür.

PostgreSQL çözümleri #

PostgreSQL mimarilerinde pgBackRest tercih ediyoruz. Full, differential ve incremental yedekleme tiplerini native olarak destekleyen araç; sıkıştırma, veri saklama politikaları (retention policy), uzak sunucuya yedekleme ve WAL (Write-Ahead Logging) arşivlemesi üzerinden PITR yeteneklerini tek bir merkezde toplar. Çok sunuculu (cluster) mimarilerde yedeği doğrudan replika (standby) sunucudan alarak, aktif (primary) sunucunun yükünü artırmadan yedekleme yapmak da mümkündür.

Daha küçük ölçekli sistemlerde ise PostgreSQL ile birlikte gelen pg_basebackup yeterli olmaktadır. Ek bir bileşen gerektirmez ve WAL arşivlemesiyle entegre edildiğinde PITR sağlar. Hangi aracın kullanılacağı sistemin ölçeğine ve veri saklama ihtiyaçlarına göre belirlenir. Büyük ölçekli bir veritabanını pg_basebackup ile yönetmeye çalışmak da, küçük bir sistemi pgBackRest ile karmaşıklaştırmak da gereksiz operasyonel maliyet yaratır.

Her iki araç da açık kaynak lisansa sahiptir. Kullanım ve müşteri sistemine entegrasyon hakkımız buradan doğar; kurulum, yapılandırma ve sonrasındaki operasyonel bakım tarafımızdan yürütülür.

MongoDB çözümleri #

MongoDB tarafında Percona Backup for MongoDB kullanıyoruz. Araç, hem ReplicaSet hem de sharded cluster kurulumlarında tutarlı yedek almayı sağlar; mantıksal (logical) ve fiziksel (physical) yedekleme tiplerini destekler ve oplog arşivlemesi yapılandırıldığında PITR (Point-in-Time Recovery) yeteneğini aynı araç üzerinden verir.

Sharded cluster kurulumlarında tutarlılık ayrıca ele alınması gereken bir sorundur. Her parçadan (shard) ayrı ayrı mongodump almak, parçaların farklı anlara ait kopyalarını üretir; birlikte geri yüklendiklerinde küme tutarlı bir duruma gelmez. Percona Backup for MongoDB yedeği küme genelinde eşgüdümlü aldığı için bu sorun ortadan kalkar.

mongodump ve mongorestore, tek ReplicaSet kurulumlarında ve koleksiyon düzeyinde kurtarma ihtiyaçlarında yeterlidir. Hangi aracın kullanılacağı veri boyutuna, kurtarma hedefine ve mimarinin sharded olup olmadığına göre belirlenir.

Araç açık kaynak lisanslıdır; kullanım ve müşteri sistemine entegrasyon hakkımız buradan doğar.

Yedeklerinizin gerçekten çalıştığından nasıl emin olabilirsiniz? #

Bu sayfanın en kritik bölümü burasıdır. Bir yedekleme mekanizması iki şekilde fark ettirmeden iflas eder: ya yedek alma işlemi durur ve kimse fark etmez, ya da yedekler alınmaya devam eder ancak dosyalar bozulduğu için geri yüklenemez hâle gelir. İkinci senaryo çok daha tehlikelidir; çünkü izleme (monitoring) ekranlarında her şey “yeşil” görünmeye devam eder.

Bu riski ortadan kaldırmak için kurduğumuz her yedekleme altyapısına otomatik geri yükleme testleri entegre ediyoruz. Yedek dosyaları periyodik olarak izole bir test ortamına açılır, veritabanı ayağa kaldırılır, veri tutarlılık (consistency) kontrolleri yürütülür ve tüm sürecin süresi raporlanır. Testin sonucunda ortaya çıkan süre, kâğıt üzerinde taahhüt edilen değil, ölçümlenmiş gerçek RTO değerinizdir.

Ölçülen süre hedeflenen RTO değerinin üzerindeyse ortada bir kurtarma planı değil, yalnızca bir varsayım vardır — ve bunu sistem çöktüğünde öğrenirsiniz.

İlgili hizmetler #

Şifrelenmiş bir veritabanının yedek dosyaları da şifrelenmelidir. İki süreç birlikte kurgulanır: Veritabanı Güvenliği ve KVKK Teknik Tedbirleri

Cluster mimarisi yedeklemenin yerini almaz; replikasyon veri kaybına karşı koruma sağlamaz: Yüksek Erişilebilirlik ve Cluster Çözümleri

Yedekleme penceresinin üretim yüküne etkisi performans çalışmasının kapsamındadır: Performans Optimizasyonu ve İzleme