Küçük ekiplerde yedekleme: felaket senaryosu değil, rutin iş
Yedekleme bir felaket senaryosu egzersizi değil; verinin nerede durduğu, ne sıklıkla kopyalandığı ve geri yüklemenin gerçekten çalışıp çalışmadığı sorusuna verilen yazılı cevaptır. 3–20 kişilik ekipler için abartısız bir yedek düzeni: neyi yedekle, nereye koy, ne sıklıkla dene, geri dönüşü ölç.
Yedekleme bir felaket senaryosu egzersizi değil; verinin nerede durduğu, ne sıklıkla kopyalandığı ve geri yüklemenin gerçekten çalışıp çalışmadığı sorusuna verilen yazılı cevaptır. Bu yazıda 3–20 kişilik ekipler için abartısız bir yedek düzeni öneriyoruz: neyi yedekle, nereye koy, ne sıklıkla dene, geri dönüşü ölç.
Küçük ekiplerde yedekleme çoğu zaman iki uçta kalır: ya “bulut zaten yedekliyor” varsayımı, ya da her gece alınan ama hiç açılmamış dump dosyaları. İkisi de riski görünmez kılar.
TW Bilişim olarak yazılım ve altyapı işlerinde gördüğümüz tablo: asıl sorun araç eksikliği değil. Asıl sorun ne korunuyor, kim geri yükleyebilir ve son başarılı test ne zaman sorularının cevapsız kalması.
Bu rehber, kendi ürününü veya müşteri için özel yazılımı işleten ekipler içindir. Bulut sağlayıcı adı ikincil; önemli olan düzen.
Önce “neyi kaybetmeyiz?” — üç sınıf
Yedek politikası yazmadan önce veriyi sınıflandırmak yeter:
- Kritik iş verisi: müşteri kaydı, sipariş, fatura, üretim / saha ölçümü — kaybı doğrudan para veya yasal risk.
- Ürün durumu: uygulama ayarları, yetki tabloları, özellik bayrakları, içerik — yeniden kurmak mümkün ama pahalı.
- Yeniden üretilebilir: derlenmiş artefakt, cache, geçici log — çoğu zaman yedek şart değil; kaynak ve pipeline yeter.
Her şeyi aynı sıklıkta yedeklemek genelde boşa maliyet veya boşa güven üretir. Kritik sınıf net değilse “günlük full backup” cümlesi de net değildir.
3-2-1’i küçük ekibe indirgemek
Klasik kural hâlâ işe yarar, abartmadan:
- 3 kopya: canlı + en az iki bağımsız kopya (ör. günlük snapshot + ayrı bucket / ayrı disk)
- 2 ortam türü: mümkünse farklı depolama (aynı diskin iki klasörü sayılmaz)
- 1 offsite / ayrı hesap: ransomware veya hesap kilidi senaryosu için canlı hesabın dışına en az bir kopya
Tek VPS’te /backup klasörü, “yedek var” hissi verir; disk veya sunucu gittiğinde birlikte gider. Küçük ekip için offsite çoğu zaman ikinci bulut bucket’ı veya ayrı bölge yeterlidir — kurumsal tape kütüphanesi şart değil.
Veritabanı ile dosyayı ayırın
Çoğu ürün iki katmandan oluşur:
| Katman | Tipik içerik | Dikkat |
|---|---|---|
| Veritabanı | İş kayıtları, ilişkiler | Tutarlı snapshot / dump; şifreli yedek |
| Nesne / dosya | yüklenen PDF, görsel, firmware | DB’deki path ile dosya birlikte anlamlı |
| Secret / config | API anahtarları, bağlantı dizeleri | Yedekte düz metin tutulmaz; secret store + erişim kaydı |
“Sadece DB dump’ı var, yüklenen dosyalar yok” veya tersi — geri yükleme yarım kalır. İkisini aynı RPO (ne kadar geriden kabul?) hedefine bağlayın.
Sıklık: RPO ve RTO’yu bir cümleyle yazın
Jargon şart değil; iki soru yeter:
- RPO (kayıp toleransı): En fazla ne kadarlık veri kaybını göze alıyoruz? (ör. 24 saat / 1 saat)
- RTO (geri dönüş süresi): Sistemi makul hale getirmek için hedef süre nedir? (ör. aynı iş günü / 4 saat)
Bu iki cümle, “her saat mi, her gece mi?” kararını verir. Saatlik yedek her ürün için gerekli değildir; fatura veya saha telemetrisi olan ürünlerde gece dump’ı yetmeyebilir.
Geri yükleme testi olmadan yedek yok
Alınmayan yedek yoktur; açılmayan yedek vardır. Küçük ekip için pratik ritim:
- Ayda bir (veya her büyük sürüm sonrası): staging’e geri yükleme
- Kontrol listesi: DB ayağa kalkıyor mu, dosyalar bağlanıyor mu, login çalışıyor mu, son bilinen kayıt görünüyor mu?
- Süreyi not edin — RTO iddiası ancak ölçülünce gerçektir
Testi “yıllık felaket tatbikatı” yapmak yerine 30–60 dakikalık rutin haline getirmek, gerçekte yapılmasını sağlar.
Kim erişir, kim siler?
Yedek bucket’ı herkesin yazabildiği bir klasörse, yanlışlıkla veya kötü niyetle silme riski canlı veriden farksızdır.
Pratik kurallar:
- Yedek deposunda silme / overwrite yetkisi dar tutulur
- Mümkünse object lock / immutability (kısa süre bile) ransomware’e karşı faydalıdır
- Staging ve prod yedekleri ayrı prefix veya ayrı bucket
- “Yedeği sildim, yer açıldı” operasyonu çift onay veya gecikmeli silme ister
Gözlemlenebilirlik yazımızdaki gibi: sahipsiz bir yedek paneli, sahipsiz bir alarm gibidir — bir süre yeşil görünür, sorunca kimse anlatamaz.
Uygulama kodu ≠ veri
Git, kod ve infra tanımı için yedektir; müşteri verisi için değildir. “Repo GitHub’da, o yüzden yedekliyiz” cümlesi yalnızca kaynak kodunu kapsar.
Tersinden: sadece DB dump’ı alıp uygulama sürümünü (migration geçmişi, image tag) kaydetmemek, geri yüklemeyi yarım bırakır. Yedek kaydına hangi uygulama sürümüyle uyumlu bilgisini ekleyin — CI/CD yazısındaki sürüm kimliği burada da işe yarar.
Pratik checklist
| Madde | Net mi? | Not |
|---|---|---|
| Kritik veri sınıfları yazılı | ☐ | 1–2 paragraf yeter |
| RPO / RTO birer cümle | ☐ | Ürüne göre |
| DB + dosya (gerekirse) birlikte plan | ☐ | Path tutarlılığı |
| En az bir offsite / ayrı hesap kopya | ☐ | Aynı disk sayılmaz |
| Yedek erişimi daraltılmış | ☐ | Silme yetkisi sınırlı |
| Son geri yükleme testi tarihi | ☐ | Staging’de |
| Hangi uygulama sürümüyle uyumlu | ☐ | Tag / SHA |
| Secret’lar yedekte düz metin değil | ☐ | Ayrı store |
SSS
Bulut sağlayıcının “dayanıklılığı” yedek yerine geçer mi?
Hayır. Bölgesel çoğaltma altyapı arızasına karşıdır; yanlış silme, bozuk migrate veya hesap ele geçirme için ayrı kopya gerekir.
Sadece snapshot yeter mi?
Snapshot iyi bir başlangıçtır; geri yükleme testi ve offsite kopya olmadan tek başına politika sayılmaz. Snapshot’ın tutulma süresi ve silinme politikası da yazılı olmalı.
Kişisel veri (leads, müşteri) yedekte nasıl durmalı?
Mümkünse şifreli; erişim log’u ve saklama süresi bilinçli. Bu yazı hukuk metni değil — KVKK süreçleri için danışmanlık ayrıdır; teknik olarak “herkesin okuyabildiği düz dump” kabul edilemez.
Yedekleme CI/CD’nin parçası mı?
Ayrı bir iştir ama aynı disiplinle yürür: otomatik iş, görünür sonuç, periyodik doğrulama. Deploy pipeline’ı yeşilken yedek job’ının üç gündür kırık olması sık görülür.
TW Bilişim bu konuda ne yapıyor?
Mevcut host ve veri modelinize uygun, abartısız yedek + geri yükleme rutini kuruyoruz: neyin kritik olduğu net, offsite kopya var, staging’de periyodik deneme yapılabilir. Amaç felaket sunumu değil; ekibinizin güvendiği bir geri dönüş yolu bırakmak.
Sonuç
Sırayı basit tutun: neyi kaybetmeyiz → ne sıklıkla kopyala → nereye (offsite dahil) koy → kim erişir → staging’de geri yüklemeyi dene → süreyi not et. Bu sıra netse araç seçimi (pg_dump, snapshot, object storage) ikincil kalır.
Yedek ve geri dönüş planınızı birlikte sadeleştirmek isterseniz: iletişim veya [email protected].