Geçenlerde kendi geliştirdiğim bir yan ürünümün backend’inde, rutin bir performans kontrolü sırasında, otomatik yedekleme cron job’larının haftalardır sessizce başarısız olduğunu fark ettim. Disk alanı dolduğunda hataları fark etsem de, daha öncesinde rsync komutunun bağımsız bir tmpfs bağlama noktasını hedef alması gibi basit bir yapılandırma hatası yüzünden yedeklerin aslında hiçbir yere gitmediğini gördüm. Bu durum, self-hosting ortamlarında veri yedeklemesinin ne kadar sinsi sorunlara yol açabileceğini ve düzenli kontrolün ne denli kritik olduğunu bana bir kez daha hatırlattı.
Self-hosting, kişisel projelerimizden küçük ölçekli ticari uygulamalara kadar geniş bir alanı kapsar. Kendi sunucularımızın veya VPS’lerimizin tam kontrolünü sağlarken, aynı zamanda tüm sorumluluğu da üzerimize alırız. Bu sorumluluğun en temel ve en çok göz ardı edilen bileşenlerinden biri de şüphesiz veri yedeklemesidir. Çoğu zaman bir sorun yaşanana kadar değeri anlaşılmayan yedekleme, aslında her altyapı stratejisinin merkezinde yer almalıdır.
Veri Yedeklemesi Neden Sürekli Gözden Kaçar?
Yedekleme, genellikle bir “yap ve unut” görevi olarak algılanır, ancak bu yaklaşım ciddi riskler taşır. Benim de yaşadığım gibi, bir kez kurulan yedekleme sistemleri, genellikle uzun süre dokunulmaz ve çalışıp çalışmadığı nadiren kontrol edilir. Bu durum, özellikle self-hosting ortamlarında, küçük bir yapılandırma değişikliğinin veya disk alanı probleminin yedekleme zincirini tamamen kırmasına neden olabilir.
Modern sistemlerde bağımlılıklar ve servisler arasındaki etkileşim giderek karmaşıklaşıyor. Bir veritabanı yedeğinin başarıyla tamamlandığını düşünürken, aslında ilgili log dosyalarının veya konfigürasyonların eksik olduğunu fark etmeyebiliriz. Bu tür eksiklikler, tam bir felaket kurtarma senaryosunda sistemin yeniden çalışır hale gelmesini engelleyebilir. Bu yüzden, yedekleme sürecini sadece dosya kopyalamak olarak görmekten ziyade, sistemin tamamının bir anlık görüntüsünü almak gibi ele almalıyız.
Yedekleme Stratejileri: Tam, Diferansiyel ve Artımlı Yaklaşımlar Nelerdir?
Veri yedekleme stratejileri, depolama alanından kurtarma süresine kadar birçok faktörü etkileyen temel seçimlerdir. Genel olarak üç ana yaklaşımdan bahsedebiliriz: Tam (Full), Diferansiyel (Differential) ve Artımlı (Incremental) yedeklemeler. Her birinin kendine özgü avantajları ve dezavantajları bulunur ve doğru seçimi yapmak, kaynaklarımızı verimli kullanmak ve ihtiyaç anında hızlıca kurtarma yapmak için kritiktir.
Tam yedekleme, tüm verinin eksiksiz bir kopyasını almayı ifade eder. Bu yöntem en güvenli seçenek gibi görünse de, büyük veri setleri için oldukça fazla depolama alanı ve uzun yedekleme süresi gerektirir. Öte yandan, kurtarma işlemi en basit olanıdır çünkü tek bir yedekleme setinden tüm veriyi geri yükleyebilirsiniz. Diferansiyel yedekleme ise, son tam yedeklemeden bu yana değişen tüm veriyi kopyalar. Bu, tam yedeklemeye göre daha az depolama alanı ve daha kısa yedekleme süresi gerektirir, ancak kurtarma için hem son tam yedeğe hem de son diferansiyel yedeğe ihtiyacınız olur. Artımlı yedekleme ise, son herhangi bir yedeklemeden (tam veya artımlı) bu yana değişen veriyi kopyalar. Bu yöntem en az depolama alanı ve en kısa yedekleme süresini sunar ancak kurtarma işlemi en karmaşık olanıdır; tüm artımlı yedek zincirinin ve son tam yedeğin sırasıyla geri yüklenmesi gerekir.
graph TD; A["Tam Yedekleme"] --> B["Tüm Veri Kopyalanır"]; B --> C["Yüksek Depolama Maliyeti"]; B --> D["Kolay Kurtarma"]; E["Diferansiyel Yedekleme"] --> F["Son Tam Yedeklemeden Değişenler"]; F --> G["Orta Depolama Maliyeti"]; F --> H["Tam + Diferansiyel ile Kurtarma"]; I["Artımlı Yedekleme"] --> J["Son Yedeklemeden Değişenler"]; J --> K["Düşük Depolama Maliyeti"]; J --> L["Tüm Zincir ile Zor Kurtarma"];
Ben genellikle kritik veriler için haftalık tam yedeklemeler ve günlük artımlı yedeklemeler kombinasyonunu tercih ediyorum. Bu yaklaşım, hem depolama maliyetini optimize ediyor hem de belirli bir geri dönüş noktasına (RPO) ulaşma esnekliği sağlıyor. Özellikle bir üretim ERP’sinde çalışırken, operasyonel verilerin her saat başı artımlı olarak yedeklenmesi, olası bir veri kaybı durumunda iş sürekliliğini sağlamak için vazgeçilmez bir stratejiydi.
Self-Hosting Ortamında Yedekleme Hedefleri (RPO/RTO) Nasıl Belirlenir?
Yedekleme stratejisi belirlerken Recovery Point Objective (RPO) ve Recovery Time Objective (RTO) kavramları hayati öneme sahiptir. RPO, bir felaket durumunda kaybedilebilecek maksimum veri miktarını (zaman cinsinden) ifade eder. Örneğin, 4 saatlik bir RPO, en kötü senaryoda son 4 saatlik veriyi kaybedebileceğiniz anlamına gelir. RTO ise, bir felaket sonrası sistemin ne kadar sürede tekrar çalışır duruma gelmesi gerektiğini belirtir. Bu iki hedef, yedekleme sıklığınızı, depolama seçeneklerinizi ve kurtarma süreçlerinizin karmaşıklığını doğrudan etkiler.
Kendi yan ürünlerim için genellikle 4-6 saatlik bir RPO ve 24 saatlik bir RTO hedefliyorum. Bu hedefler, veri kayıplarının kabul edilebilir düzeyde kalmasını sağlarken, aynı zamanda maliyet ve operasyonel karmaşıklığı da makul seviyelerde tutuyor. Ancak, bir müşteri projesinde, özellikle finansal işlemlerin döndüğü bir sistemde, RPO dakikalarla, RTO ise birkaç saatle ölçülebilir. Bu durumda sürekli replikasyon veya çok sık artımlı yedeklemeler gibi daha agresif stratejiler devreye girer.
RPO’yu belirlerken, veri değişim hızını ve veri kaybının maliyetini göz önünde bulundururum. Eğer veri sürekli değişiyorsa (örneğin bir mesaj kuyruğu veya yoğun işlem gören bir veritabanı), RPO’nun düşük tutulması gerekir. RTO için ise, sistemin karmaşıklığı, kurtarılacak veri miktarı ve kurtarma ekibinin yetenekleri gibi faktörler devreye girer. Otomatik kurtarma araçları ve iyi belgelenmiş bir felaket kurtarma planı, RTO’yu önemli ölçüde düşürebilir.
PostgreSQL ve Redis Gibi Servislerin Yedeklemesindeki Özel Durumlar
Self-hosting ortamlarında genellikle belirli veri depolama servisleri kullanırız ve bunların yedekleme yaklaşımları, basit dosya kopyalamadan farklılık gösterir. PostgreSQL ve Redis, özellikle veri bütünlüğü ve performans açısından kendi özel durumlarını barındırır. Bu servisleri yedeklerken, sadece veriyi değil, verinin tutarlılığını ve kurtarılabilirliğini de sağlamak gerekir.
PostgreSQL için pg_basebackup aracı, veritabanının fiziksel bir kopyasını almanın en güvenli yollarından biridir. Ayrıca, Write-Ahead Log (WAL) arşivleme mekanizması, point-in-time recovery (PITR) yani belirli bir zamana geri dönme yeteneği sağlar. Ben genellikle pg_basebackup ile düzenli tam yedekler alır ve WAL dosyalarını ayrı bir depolama alanına sürekli olarak arşivlerim. Bu, bana veri kaybı durumunda son işlemi bile geri alma esnekliği sunar. Ancak, WAL bloat’ı takip etmek önemlidir; aşırı WAL dosyası birikimi disk alanı sorunlarına yol açabilir ve yedekleme süreçlerini etkileyebilir. Ayrıca, PostgreSQL’in connection pool tuning ayarlarının yedekleme sırasında bağlantı kısıtlamalarına yol açmaması için dikkatli olmak gerekir.
# PostgreSQL base backup alma örneği
pg_basebackup -h localhost -p 5432 -U backup_user -D /var/lib/postgresql/backups/base_backup_$(date +%Y%m%d) -Ft -X fetch -P -vRedis tarafında ise durum biraz daha farklıdır. Redis, veriyi bellekte tutan bir in-memory veritabanıdır ve kalıcılık için RDB snapshot’ları veya AOF (Append Only File) persistence mekanizmalarını kullanır. RDB snapshot’ları belirli aralıklarla veritabanının bir anlık görüntüsünü diske yazar. AOF ise, Redis’e gelen her yazma işlemini bir log dosyasına kaydeder. Benim tercihim genellikle her ikisini de kullanmaktır: AOF ile daha düşük bir RPO hedeflerken, RDB snapshot’ları ile daha hızlı kurtarma noktaları oluştururum. Redis’in OOM eviction policy seçimleri de yedekleme sırasında kritik olabilir; yanlış bir politika, belleğin dolması durumunda veri kaybına yol açabilir.
# Redis persistence ayarları (redis.conf içinde)
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysecBu servislerin kendine özgü mekanizmalarını anlamadan yapılan yedeklemeler, çoğu zaman eksik veya tutarsız veriye yol açabilir. Bu nedenle, her servis için resmi dokümantasyonu dikkatlice incelemek ve en iyi uygulama yöntemlerini takip etmek önemlidir.
Yedekleme Doğrulama ve Kurtarma Tatbikatları: Olmazsa Olmaz Adımlar
Bir yedekleme planının en zayıf halkası, yedeklerin gerçekten işe yarayıp yaramadığının test edilmemesidir. “Yedeğim var” demekle, “Yedeğimi başarıyla geri yükleyebilirim” demek arasında büyük bir fark vardır. Bu yüzden, yedekleme doğrulama ve düzenli kurtarma tatbikatları, benim için operasyonel süreçlerin vazgeçilmez bir parçasıdır. Gerekirse, bu tatbikatlar için ayrı bir test ortamı kurmak bile bu çabaya değer.
Benim pratiğimde, yedekleme işlemleri tamamlandıktan sonra otomatik bir doğrulama süreci devreye girer. Bu süreç, yedeklenen dosyaların bütünlüğünü kontrol eder (örneğin checksum karşılaştırması), veritabanı yedeklerinin basit bir şekilde geri yüklenebilirliğini dener ve kritik servislerin ayağa kalkıp kalkmadığını kontrol eder. Örneğin, bir PostgreSQL yedeğini ayrı bir Docker container’ına geri yükleyip, üzerinde basit bir SQL sorgusu çalıştırmak, yedeğin sağlam olduğunu teyit etmenin etkili bir yoludur.
# PostgreSQL yedeğini doğrulama için örnek komut dizisi
# Yedek dosyasını geçici bir dizine kopyala
cp /path/to/backup/db.sql.gz /tmp/db_restore_test/
gzip -d /tmp/db_restore_test/db.sql.gz
# Docker konteynerini başlat (boş bir PostgreSQL ile)
docker run --rm --name pg_restore_test -e POSTGRES_PASSWORD=mysecretpassword -d postgres:14
# Veriyi geri yükle
docker exec -i pg_restore_test psql -U postgres < /tmp/db_restore_test/db.sql
# Basit bir sorgu ile veritabanının çalıştığını doğrula
docker exec pg_restore_test psql -U postgres -c "SELECT COUNT(*) FROM your_table;"
# Konteyneri durdur
docker stop pg_restore_testYedekleme doğrulamanın bir adım ötesi ise kurtarma tatbikatlarıdır. Belirli aralıklarla (örneğin çeyrek yılda bir), gerçek bir felaket senaryosunu simüle ederek sıfırdan bir sistem kurulumu ve veri kurtarma işlemini baştan sona gerçekleştiririm. Bu tatbikatlar, sadece yedeklerin çalışıp çalışmadığını değil, aynı zamanda felaket kurtarma dokümantasyonumun güncel olup olmadığını, ekibimin (veya kendi kendimin) kurtarma sürecine ne kadar hakim olduğunu da ortaya çıkarır. Bir üretim ERP’sinde, bu tatbikatları düzenli olarak yaparak, en kritik sistemlerin bile beklenmedik bir durumda ne kadar hızlı ayağa kalkabileceğini test ederdik. Bu tatbikatlar sırasında karşılaştığımız MTU/MSS mismatches veya DNS negative caching gibi network seviyesi gizli sorunlar, genel sistem dayanıklılığımızı artırmamıza yardımcı oldu.
Otomasyon ve İzleme: Manuel Hataların Önüne Geçmek
Manuel yedekleme süreçleri, insan hatasına açık kapı bırakır ve sürdürülebilir değildir. Bu nedenle, self-hosting ortamlarında yedekleme süreçlerinin mümkün olduğunca otomatikleştirilmesi ve sürekli izlenmesi kritik önem taşır. Otomasyon, yedeklemelerin düzenli ve hatasız bir şekilde çalışmasını sağlarken, izleme ise olası sorunları erkenden tespit etmemize olanak tanır.
Yedekleme otomasyonu için cron job’ları veya systemd birimleri vazgeçilmezdir. systemd timers, cron’a göre daha esnek ve güvenilir bir alternatif sunabilir; örneğin, sistem açılışında bile zamanlayıcıları tetikleyebilir ve daha detaylı loglama imkanları sağlar. Bir projemde, systemd birimlerini kullanarak belirli bir veritabanının her 4 saatte bir yedeğini alıp farklı bir depolama alanına taşımak için bir pipeline kurmuştum. Bu sayede, manuel müdahaleye gerek kalmadan veri güvenliğini sağlayabiliyordum.
# systemd timer birimi örneği (backup.timer)
[Unit]
Description=Run database backup every 4 hours
[Timer]
OnCalendar=*-*-* *:00:00
Persistent=true
[Install]
WantedBy=timers.target# systemd service birimi örneği (backup.service)
[Unit]
Description=Database backup service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup_script.shİzleme ise, otomasyonun tamamlayıcısıdır. Prometheus ve Grafana gibi araçlarla yedekleme süreçlerinin durumunu (başarılı/başarısız sayısı, yedekleme süresi, disk alanı kullanımı) görselleştirmek, olası sorunları hızlıca tespit etmemizi sağlar. journald logları üzerinden belirli anahtar kelimeleri (örneğin “backup failed”) arayan uyarılar kurmak da etkili bir yöntemdir. Ayrıca, fail2ban gibi araçlarla yedekleme sunucularına yapılan yetkisiz erişim denemelerini engellemek, genel güvenlik duruşumuzu güçlendirir. Bir sunucuda, SSH’a brute-force denemeleri başladığında, fail2ban sayesinde otomatik olarak engellemeler devreye girer ve yedekleme mekanizmalarını korur.
Felaket Kurtarma Planı ve Yedekleme Lokasyon Çeşitliliği
Yedekleme, felaket kurtarma planının sadece bir parçasıdır. Gerçek bir felaket (sunucu arızası, veri merkezi kesintisi, siber saldırı) durumunda, sadece yedeklerin olması yeterli değildir; aynı zamanda bu yedeklere nasıl erişileceği ve sistemin nasıl geri yükleneceği konusunda net bir plana sahip olmak gerekir. Bu planın önemli bir bileşeni de yedekleme lokasyonlarının çeşitliliğidir.
Tek bir fiziksel veya mantıksal konumda tutulan yedekler, o konumun başına bir şey gelmesi durumunda tamamen işlevsiz hale gelebilir. Bu nedenle, “3-2-1 kuralı” gibi yaklaşımlar popülerdir: verinin 3 kopyası, 2 farklı ortamda ve 1 kopyası offsite (uzak konumda) tutulmalıdır. Kendi altyapımda, ana sunucumdaki verilerin bir kopyasını aynı sunucudaki ayrı bir disk bölümüne, bir başka kopyasını ise ağ üzerindeki farklı bir depolama sunucusuna ve son olarak da bir S3 uyumlu bulut depolama hizmetine gönderiyorum. Bu, bölgesel bir kesinti veya yerel bir disk arızası durumunda bile verilere erişebilmemi sağlar.
Felaket kurtarma planında, yedekleme lokasyonlarına erişim yöntemleri de detaylandırılmalıdır. Örneğin, offsite yedeklere erişim için VPN topolojileri veya Zero Trust Network Access (ZTNA) çözümleri kullanılabilir. Ayrıca, yedeklerin şifrelenmesi ve erişim kimlik bilgilerinin güvenli bir şekilde saklanması, siber güvenlik açısından vazgeçilmezdir. Bir üretim ERP’si projesinde, felaket kurtarma planımızı düzenli olarak güncelleyip, farklı senaryolar için detaylı adımlar belirleyerek, olası bir kesintiye karşı hazırlıklı olmayı amaçlamıştık. Bu planın en kritik maddelerinden biri, veri yedeklemelerinin farklı coğrafi konumlarda tutulması ve bu lokasyonlara erişim için çok faktörlü kimlik doğrulamanın zorunlu kılınmasıydı.
Sonuç
Self-hosting, sağladığı özgürlük ve kontrolle birlikte önemli sorumlulukları da beraberinde getirir. Veri yedeklemesi, bu sorumlulukların başında gelir ve genellikle en çok ihmal edilen alandır. Kendi deneyimlerimden yola çıkarak gördüm ki, bir yedekleme sisteminin varlığı tek başına yeterli değil; bu sistemin güvenilirliğini sürekli sorgulamak, düzenli olarak doğrulamak ve olası senaryolara karşı test etmek esastır.
Yedekleme stratejilerini doğru belirlemek, RPO ve RTO hedeflerini gerçekçi bir şekilde tanımlamak, PostgreSQL veya Redis gibi özel servislerin nüanslarını anlamak ve en önemlisi, yedekleme süreçlerini otomatize edip izlemek, beklenmedik sorunlara karşı en iyi savunma hattını oluşturur. Unutmayalım ki, yedekleme bir ürün değil, bir süreçtir ve sürekli ilgi ve bakım gerektirir. Bir sonraki adım, kendi self-hosting ortamınızın yedekleme planını gözden geçirmek ve bir kurtarma tatbikatı planlamak olabilir.