Her Veritabanı Yöneticisi (DBA) ve Sistem Mühendisi, kariyerinin bir noktasında veritabanını yedeklemek için özel bir kabuk (shell) betiği yazmıştır. Bu neredeyse bir geçiş töreni gibidir. Bir projenin ilk aşamalarında, gzip ile borulanan (piped) mysqldump veya pg_dump çalıştıran basit bir cron işi; zarif, hafif ve uygun maliyetli bir çözüm gibi görünür.
Ancak altyapı ölçeklendikçe, veri hacimleri büyüdükçe ve çalışma süresi (uptime) SLA’leri katılaştıkça, o 10 satırlık Bash betiği sessizce saatli bir bombaya dönüşür. Üretim ortamları; yüksek erişilebilirlik, katı Kurtarma Noktası Hedefleri (RPO) ve hızlı Kurtarma Süresi Hedefleri (RTO) gerektirir. Bu ortamlarda kendi hazırladığınız (DIY) yedekleme betiklerine güvenmek; veri tutarlılığı, sessiz hatalar, güvenlik açıkları ve yönetilemez kurtarma süreçleri ile ilgili ciddi riskler doğurur.
Bu makalede, DIY veritabanı yedekleme betiklerinin mimari kusurlarını ve gizli tehlikelerini inceleyecek, mantıksal ve fiziksel yedeklemelerin teknik tuzaklarını keşfedecek ve görev açısından kritik verilerinizi korumak için CloudSave gibi kurumsal düzeydeki çözümlere nasıl geçiş yapacağınızı tartışacağız.
Basitlik Yanılsaması: Klasik DIY Betiğini İncelemek
Tehlikeyi anlamak için önce tipik bir DIY yedekleme betiğinin anatomisine bakmalıyız. Bir MySQL veritabanı için standart bir yaklaşım genellikle şuna benzer:
#!/bin/bash
# Basit DIY MySQL Yedekleme Betiği
BACKUP_DIR="/mnt/backups"
DATE=$(date +%F)
DB_USER="admin"
DB_PASS="SuperSecret123!"
mysqldump -u $DB_USER -p$DB_PASS my_database | gzip > $BACKUP_DIR/mydb_$DATE.sql.gz
# 30 günden eski yedekleri sil
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
İlk bakışta bu betik amacına ulaşır: veriyi çıkarır, sıkıştırır ve saklama süresini yönetir. Ancak yüzeyin altında, üretim ortamında er ya da geç veri kaybına yol açacak kritik kusurlarla doludur.
Tehlike 1: Sessiz Hatalar ve Boru (Pipe) Tuzağı
DIY betiklerinin en sinsi tehlikelerinden biri sessiz hatadır. Yukarıdaki betikte, mysqldump komutu doğrudan gzip‘e borulanır (|).
Bash’te bir boru hattının çıkış durumu, boru hattındaki son komutun çıkış durumudur. Veritabanı sunucusunun belleği biterse, bağlantı koparsa veya dump işlemi sırasında kilitli bir tabloyla karşılaşılırsa, mysqldump başarısız olur ve bir hata verir. Ancak gzip, aldığı kısmi çıktıyı başarıyla sıkıştıracak ve 0 (başarılı) durum koduyla çıkacaktır.
Cron işinin çıkış kodunu kontrol eden izleme sisteminiz, başarılı bir yedekleme rapor edecektir. Diskte geçerli bir .gz dosyanız olacaktır ancak içinde kesilmiş, işe yaramaz bir SQL dosyası bulunacaktır. Bunu ancak kritik bir geri yükleme yapmaya çalıştığınızda keşfedeceksiniz.
Azaltma (ve sınırları)
Mühendisler genellikle Bash’te katı hata işlemeyi etkinleştirerek bunu yamamaya çalışırlar:
set -e
set -o pipefail
set -o pipefail, boru hattındaki herhangi bir komut başarısız olursa betiğin başarısız olmasını sağlasa da, yine de betiğin etrafında sağlam uyarı, günlük kaydı ve yeniden deneme mekanizmaları oluşturmanızı gerektirir. Geçici bir ağ hatası saat 02:00’de bir hataya neden olduğunda, bir DIY betiği basitçe durur. Kurumsal platformlar bu geçici hataları akıllı, üstel geri çekilme (exponential backoff) yeniden denemeleriyle yönetir.
Tehlike 2: Veri Tutarlılığı ve Kilitleme Kabusları
DIY betikleri büyük ölçüde mantıksal yedeklemelere (mysqldump, pg_dump) dayanır. Mantıksal yedeklemeler, tüm tablolarda SELECT ifadeleri çalıştırarak verileri çıkarır. Yüksek düzeyde işlemsel bir üretim veritabanında veriler sürekli değişir. Bir betiğin 100GB’lık bir veritabanını dump etmesi 45 dakika sürerse, dump’ın başındaki veriler sonundaki verilerden 45 dakika daha eski olacak ve ACID uyumluluğunu ihlal edecektir.
MySQL İşlemsel Tutarlılığı
InnoDB kullanarak MySQL’de tutarlı bir anlık görüntü (snapshot) elde etmek için belirli bayrakları geçmeniz gerekir:
mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql
--single-transaction bayrağı, yalıtım seviyesini REPEATABLE READ olarak ayarlar ve dump işleminden önce bir işlem başlatır. Ancak veritabanınız hala eski MyISAM tabloları içeriyorsa, bu bayrak onların kilitlenmesini önlemeyecek ve yedekleme çalışırken üretim okuma/yazma trafiğini potansiyel olarak durduracaktır. Ayrıca, yedekleme sırasında geliştiriciler tarafından yürütülen herhangi bir ALTER TABLE, DROP TABLE veya RENAME TABLE ifadesi REPEATABLE READ anlık görüntüsünü bozacak ve dump’ın başarısız olmasına neden olacaktır.
PostgreSQL ve WAL Arşivleme
PostgreSQL için pg_dump tutarlı mantıksal yedeklemeler sağlar, ancak yalnızca mantıksal yedeklemeler Noktasal Kurtarma (PITR) sağlayamaz. Veritabanınız saat 16:00’da çökerse ve son cron betiğiniz gece yarısı çalıştıysa, 16 saatlik veriyi kaybedersiniz.
PITR’ye ulaşmak, Yazma Öncesi Günlüklerin (WAL) sürekli arşivlenmesini gerektirir. archive_command‘ı güvenli bir şekilde işlemek için bir DIY betiği yazmak oldukça zordur.
# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'
Hedef depolama (/mnt/wal_archive/) dolarsa veya kullanılamaz hale gelirse, archive_command başarısız olur. PostgreSQL daha sonra birincil disk dolana kadar WAL dosyalarını yerel olarak biriktirir ve bu da tam bir veritabanı kesintisine neden olur. DIY betikleri, bir kesinti meydana gelmeden önce WAL birikimini izlemek ve yöneticileri uyarmak için gereken telemetriye nadiren sahiptir.
Tehlike 3: Saklama Ruleti
İlk betiğimizdeki saklama komutuna geri bakın:
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
Bu, gerçekleşmeyi bekleyen felaket niteliğinde bir veri kaybı olayıdır. Bir yapılandırma değişikliğinin mysqldump kimlik doğrulamasını bozduğu bir senaryo hayal edin. Betik yeni yedekler oluşturamaz, ancak find komutu her gece çalışmaya devam eder ve 30 günden eski dosyaları görev bilinciyle siler.
30 günlük sessiz yedekleme başarısızlığından sonra, find komutu kalan son iyi yedeğinizi de silecektir. Artık elinizde hiç yedek kalmamıştır.
CloudSave gibi kurumsal yedekleme yazılımları durum bilgisi olan (stateful) saklama politikaları kullanır. “30 günden eski yedekleri sil” ile “eski verileri temizlemeden önce en az 30 başarılı kurtarma noktasının var olduğundan emin ol” arasındaki farkı anlar.
Tehlike 4: Güvenlik, Şifreleme ve Uyumluluk Kör Noktaları
Fidye yazılımı ve katı uyumluluk çerçeveleri (GDPR, HIPAA, SOC 2) çağında, yedeklemeler birincil hedeftir. DIY betikleri genellikle güvenlik en iyi uygulamalarını ihlal eder:
- Sabit Kodlanmış Kimlik Bilgileri: Veritabanı şifrelerini düz metin betiklerinde veya cron tanımlarında saklamak büyük bir güvenlik riskidir. MySQL’in
mysql_config_editorveya PostgreSQL’in.pgpassdosyası gibi araçlar bunu hafifletse de, yine de sunucudaki yerel anahtar dosyalarını yönetmeyi gerektirirler. - Bekleyen Verinin Şifrelenmemesi: Ham SQL’i bir diske dökmek, hassas PII/PHI verilerini açığa çıkarır.
- Karmaşık Şifreleme Boru Hatları: GPG kullanarak yedekleri anında şifrelemeye çalışmak, ciddi CPU yükü ve anahtar yönetimi karmaşıklıkları getirir.
# DIY şifreli yedekleme boru hattı
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg
Sunucu ele geçirilirse, saldırgan hem şifreli yedeğe hem de /etc/keys/backup.key dosyasına erişebilir ve bu da şifrelemeyi işe yaramaz hale getirir. Ayrıca, GPG anahtarını oluşturan DBA şirketten ayrılırsa ve anahtar kaybolursa, yedekler kurtarılamaz hale gelir.
Tehlike 5: RTO Gerçeklik Kontrolü (Geri Yükleme, Yedeklemekten Daha Zordur)
Bir yedeğin nihai testi geri yüklemedir. DIY betikleri tarafından oluşturulan mantıksal yedeklemelerin geri yüklenmesi oldukça yavaştır. 500GB’lık bir SQL dump’ının oluşturulması 15 dakika sürebilir, ancak geri yüklenmesi veritabanı motorunun SQL’i ayrıştırmasını, dizinleri yeniden oluşturmasını ve kısıtlamaları yeniden hesaplamasını gerektirir. Bu saatler, hatta günler sürebilir ve RTO’nuzu yok edebilir.
Büyük üretim veritabanları için fiziksel yedeklemeler (gerçek veri dosyalarını kopyalamak) zorunludur. Percona XtraBackup veya pg_basebackup gibi araçlar mevcut olsa da, bunları DIY Bash betikleriyle sarmalamak oldukça karmaşıktır. LVM anlık görüntülerini yönetmeli, dosya sistemi sessizliğini (quiescing) sağlamalı ve yedeğin ağ arayüzünü doyurmadan tesis dışına aktarıldığından emin olmalısınız.
LVM Anlık Görüntü Tuzağı
Birçok mühendis LVM anlık görüntülerini kullanarak “sıfır kesinti” fiziksel yedeklemeleri denemeye çalışır:
# Bir anlık görüntü oluştur
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol
# Bağla ve kopyala
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql
Veritabanı yazma G/Ç’sinde ani bir artış yaşarsa, 20G’lik LVM anlık görüntüsü anında dolabilir. Bir LVM anlık görüntüsü dolduğunda geçersiz hale gelir ve yedekleme başarısız olur. Daha da kötüsü, yoğun kullanılan LVM anlık görüntüleri, birincil veritabanı biriminin G/Ç performansını ciddi şekilde düşürerek uygulama gecikme artışlarına neden olabilir.
Kurumsal Düzeyde Korumaya Geçiş
DIY betiklerinden kurumsal bir platforma geçiş, herhangi bir altyapı ekibi için kritik bir olgunluk dönüm noktasıdır. Amaç, “betiğin çalıştığını ummaktan”, kurtarılabilirliğin kriptografik kanıtına sahip olmaya geçmektir.
CloudSave gibi platformlar, özellikle DIY betiklerinin kör noktalarını ortadan kaldırmak için tasarlanmıştır. Uygulama farkındalığı olan aracılar dağıtarak CloudSave, tabloları kilitlemeden veya performansı düşürmeden tutarlı fiziksel ve mantıksal yedeklemeleri düzenlemek için doğrudan veritabanı API’leri (MySQL, PostgreSQL, MS SQL, Oracle) ile etkileşime girer.
Betiklerden Uzaklaşmanın Temel Avantajları:
- Otomatik Doğrulama: Modern platformlar sadece yedekleme yapmaz; onları test eder. CloudSave, geçici bir veritabanı örneğini otomatik olarak başlatabilir, yedeği geri yükleyebilir, tutarlılık kontrolleri (örneğin
DBCC CHECKDB) çalıştırabilir ve ardından örneği kapatarak yedeğin gerçekten kullanılabilir olduğuna dair doğrulanmış bir rapor sunabilir. - Değiştirilemez (Immutable) Depolama: Fidye yazılımlarıyla mücadele etmek için yedeklerin değiştirilemez olması gerekir. DIY betikleri WORM (Bir Kez Yaz, Çok Kez Oku) depolamaya kolayca yazamaz. Kurumsal çözümler, S3 Object Lock ve değiştirilemez bulut depolama ile yerel olarak entegre olur ve bir sunucu tamamen ele geçirilse bile yedeklerin bir saldırgan tarafından silinememesini veya şifrelenememesini sağlar.
- Basitleştirilmiş PITR: Karmaşık
recovery.confveyapostgresql.auto.confparametrelerini kullanarak bir temel yedekleme ile yüzlerce WAL dosyasını manuel olarak birleştirmek yerine, platformlar görsel bir zaman çizelgesi sağlar. Geri yüklemek istediğiniz tam dakikayı seçersiniz ve yazılım günlük tekrarını (log replay) otomatik olarak halleder. - Tekilleştirme ve Sıkıştırma: DIY betikleri, her dosyayı ayrı ayrı sıkıştıran
gzip‘e güvenir. Kurumsal yedekleme yazılımları, yedekleri tesis dışına aktarırken depolama maliyetlerini ve ağ bant genişliğini önemli ölçüde azaltan küresel blok düzeyinde tekilleştirme kullanır.
Sonuç
Bir veritabanını yedeklemek için özel bir Bash betiği yazmak kolaydır. Sessiz boru hattı hatalarını yöneten, ACID tutarlılığını garanti eden, kriptografik anahtarları güvenli bir şekilde yöneten, saklama tabanlı veri kaybını önleyen ve katı RTO/RPO SLA’lerini garanti eden bir betik yazmak neredeyse imkansızdır.
Üretim ortamlarında veritabanı, işletmenin en kritik varlığıdır. Korunmasını birkaç yüz satırlık kabuk betiği tarafından sürdürülen bir yan proje olarak görmek, hiçbir işletmenin göze alamayacağı bir risktir. Mevcut yedekleme stratejilerinizi denetleyerek, mantıksal dump’ların sınırlamalarını anlayarak ve CloudSave gibi sağlam, otomatik platformlara geçiş yaparak, DevOps ve DBA ekipleri özel betiklerin “otobüs faktörünü” (bir kişinin ayrılmasıyla bilginin kaybolması) ortadan kaldırabilir ve verilerinin gerçekten dirençli olduğundan emin olabilirler.
