Yedekleme konusu genellikle sorun çıkana kadar gündemin en altındadır. Sunucu çalışıyorsa, uygulama açılıyorsa ve müşteri şikâyeti yoksa yedeklerin gerçekten işe yarayıp yaramadığı çoğu zaman kontrol edilmez.

Oysa KOBİ ve SaaS projelerinde yedekleme sadece “dosyaları bir yere kopyalamak” değildir. Hangi verinin ne sıklıkla yedekleneceği, yedeğin nerede tutulacağı, geri dönüş süresinin ne olacağı ve eski yedeklerin nasıl temizleneceği baştan planlanmalıdır.

Her veriyi aynı şekilde yedeklememek gerekir

Bir web uygulamasında genellikle üç farklı veri tipi bulunur:

• uygulama dosyaları,
• kullanıcıların yüklediği medya ve belgeler,
• veritabanı kayıtları.

Bu üç veri tipi aynı öneme, aynı değişim hızına ve aynı geri dönüş ihtiyacına sahip değildir. Uygulama kodu Git reposundan tekrar kurulabilir. Fakat müşteri tarafından yüklenen bir belge veya canlı veritabanı kaydı kaybolursa iş etkisi çok daha yüksek olur.

Sunucu diski tek başına yeterli değildir

Bazı projelerde dosyalar ve yedekler aynı sunucu diskinde tutulur. Bu kısa vadede kolay görünür; fakat sunucu diskinde sorun yaşandığında hem canlı veri hem de yedek aynı anda risk altına girer.

Daha sağlıklı yaklaşım, kritik yedekleri sunucudan bağımsız bir depolama alanına taşımaktır. S3 uyumlu object storage burada devreye girer. Özellikle arşiv, medya, log, export ve veritabanı dump dosyaları için object storage kullanmak operasyonu daha güvenli hale getirir.

Veritabanı yedeği ayrı düşünülmeli

SaaS projelerinde asıl kritik veri çoğu zaman veritabanındadır. Bu nedenle veritabanı yedeği sadece dosya yedeğiyle birlikte düşünülmemelidir.

• yedek ne sıklıkla alınacak?
• kaç günlük/haftalık yedek saklanacak?
• yedekten geri dönüş testi ne zaman yapılacak?
• yedek dosyaları nerede tutulacak?
• şifreleme ve erişim anahtarları nasıl korunacak?

Yedeği almak kadar, geri dönebilmeyi test etmek de önemlidir. Test edilmemiş yedek, gerçek kriz anında varsayımdan ibarettir. Yönetilen veritabanı tarafında PostgreSQL Cluster Hosting gibi çözümler, süreklilik ve bakım planı açısından ayrıca değerlendirilebilir.

3 aylık saklama penceresi nasıl planlanabilir?

KOBİ ve SaaS projelerinde sık kullanılan pratik modellerden biri 30/60/90 günlük saklama penceresidir. Günlük yedekler kısa süreli, haftalık yedekler daha uzun süreli, aylık yedekler ise arşiv amaçlı saklanabilir.

Bu modelde lifecycle kuralları önem kazanır. Eski yedeklerin elle temizlenmesi unutulabilir. Kural tabanlı saklama ve temizlik yaklaşımı, hem maliyeti hem de operasyonel riski azaltır.

Basit bir yedekleme kontrol listesi

• Canlı veri ile yedek aynı fiziksel/lojik noktada kalmamalı.
• Veritabanı ve medya dosyaları ayrı ele alınmalı.
• Yedeklerin geri dönüş testi periyodik yapılmalı.
• Erişim anahtarları uygulama koduna gömülmemeli.
• Eski yedekler lifecycle ile temizlenmeli.
• Kritik yedekler için ayrı bucket veya ayrı erişim modeli planlanmalı.

Yedekten dönüş testi ihmal edilmemeli

Birçok ekip düzenli yedek aldığını düşünür; fakat gerçek soru şudur: Bu yedekten ne kadar sürede geri dönülebilir? Yedek dosyasının var olması tek başına yeterli değildir. Dosya bozuk olabilir, eksik olabilir, yanlış dizine alınmış olabilir veya geri dönüş adımları ekip içinde bilinmiyor olabilir.

Bu nedenle belirli aralıklarla küçük geri dönüş testleri yapmak gerekir. Örneğin ayrı bir test ortamında son veritabanı yedeğini açmak, birkaç medya dosyasını geri çağırmak ve uygulamanın beklenen şekilde çalıştığını görmek iyi bir kontroldür. Bu testler kriz anında ekip üzerindeki baskıyı azaltır ve yedekleme planının gerçekten işe yaradığını gösterir.

Narweb ile nasıl ilerlenebilir?

Narweb tarafında Cloud Dedicated Server, S3 Object Storage ve PostgreSQL Cluster Hosting hizmetleri birlikte planlanarak daha düzenli bir yedekleme mimarisi kurulabilir.

Eğer mevcut projenizde yedeklerin nerede durduğu, ne kadar süre saklandığı veya geri dönüş süresinin ne olduğu net değilse, önce kısa bir yedekleme envanteri çıkarmak iyi bir başlangıçtır. Kurulum, izleme ve bakım süreçleri için Narweb DevOps Hizmeti ile destek alınabilir.