Bu rehber neyi çözer?
Linux backup yalnız dosya kopyalamak değildir; uygulama tutarlılığı, veritabanı, config, anahtar/sertifika ve restore prosedürü birlikte tasarlanmalıdır.
Neleri yedeklemeli?
Uygulama verisi, veritabanı, config, sertifika/anahtar, cron/systemd tanımları, container manifestleri ve automation repository’leri envanterlenmelidir.
Bazı ortamlarda OS imajı yerine yeniden kurulum + config automation daha hızlı olabilir.
Snapshot ve backup
LVM/ZFS/hypervisor snapshot hızlı rollback sağlar; aynı storage üzerindeyse bağımsız backup değildir.
Offsite ve mümkünse immutable kopya ayrı failure domain sağlar.
Veritabanı tutarlılığı
PostgreSQL/MySQL gibi sistemlerde desteklenen application-aware yöntemler kullanılmalıdır.
Backup kadar WAL/binlog ve restore süresi de test edilmelidir.
Restore testi
Boş sunucuya tam restore, dosya seviyesinde geri dönüş ve uygulama açılış testi periyodik yapılmalıdır.
RTO ancak ölçülmüş restore süresiyle anlamlıdır.
Sık Sorulan Sorular
rsync tek başına yedek midir?
Hayır. Retention, versioning, immutability ve offsite olmadan tam backup stratejisi değildir.
Snapshot ne kadar tutulmalı?
Storage ve değişim oranına bağlıdır; uzun retention için bağımsız backup daha uygundur.
Yedek şifrelenmeli mi?
Özellikle offsite/cloud kopyalarda uygun at-rest ve in-transit şifreleme planlanmalıdır.
Kaynaklar ve teknik referanslar
Linux Sunucu Projenizi Değerlendirelim
Mevcut Windows/Linux rollerinizi, uygulama bağımlılıklarını ve geçiş hedeflerinizi birlikte değerlendirebiliriz.
Mimari ve çalışma modeli
Linux restore için veri kadar paket sürümü, mount, servis tanımı, yapılandırma ve kimlik gereksinimi kaydedilir. Çalışan veritabanının dosyalarını sıradan kopyalamak uygulama tutarlılığını garanti etmez. Bare-metal, dosya ve uygulama geri dönüşünün kapsamı farklıdır. Container verisi ve harici depolama ayrıca keşfedilmelidir.
- 1Veri/config/envanter
- 2Tutarlı kopya
- 3Temiz OS ve mount
- 4Servis ve kullanıcı testi
Tasarım parametreleri
- Veri ve sistem bileşeni
- Yapılandırma, paket listesi, veritabanı, ACL ve anahtarları ayrı listeleyin; yalnız home kopyası tam servis kurtarmaz.
- Tutarlı snapshot
- Dosya sistemi snapshotı uygulama transactionını otomatik tutarlı kılmaz; uygulama backup yöntemiyle koordine edin.
- Kurtarma birimi
- Dosya, uygulama, veritabanı ve tüm sistem için kurtarma gereksinimlerini ayrı ayrı belirleyin. Her birinin bağımlılığı ve test yöntemi farklıdır.
- Kopyanın tutarlılığı
- Yedekleme işinin başarıyla tamamlanmasıyla yetinmeyin. Uygulama hazırlığı, günlük zinciri ve gerçek geri yükleme sonucu üzerinden tutarlılığı doğrulayın.
- Kapasite ve aktarım
- Günlük değişim, saklama, tam kopya yöntemi ve ölçülen net hızla hesap yapın. Sıkıştırma veya deduplication oranını varsaymak yerine pilotta ölçün.
- Bağımsız kurtarma
- Yedek yönetimi, anahtar, katalog ve hedef altyapının üretim kaybından sonra erişilebilirliğini sınayın.
Hesap ve uygulama örneği
Örnek temiz VM’de paketler yeniden kurulur, yapılandırma geri gelir ve uygulama verisi desteklenen yöntemle restore edilir. UID/GID, SELinux context, dosya sahipliği ve mount doğrulanır. Servis açıldıktan sonra gerçek kullanıcı işlemi ve backupın yeniden çalışması test edilir.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Restore sonrası izinler farklı | UID/GID, ACL veya xattr hedefte korunmamış olabilir. | Servis kullanıcısıyla gerçek okuma/yazma ve güvenlik bağlamını kontrol edin. |
| Yedekleme başarılı ancak geri yüklenen sistem açılamıyor | Zincir, şifreleme anahtarı, katalog veya uygulama tutarlılığı sorunu olabilir. | Ayrı hedefe küçük bir gerçek kurtarma yapın; ürün loglarını uygulama doğrulamasıyla birlikte inceleyin. |
| Aktarım süresi hedefi aşıyor | Kaynak okuma, ağ, hedef yazma veya çok sayıda küçük nesne sınırlayıcı olabilir. | Aynı zaman aralığında üç katmanın hız ve gecikmesini ölçün; yalnız hat hızına bakmayın. |
| Kapasite tahminden hızlı büyüyor | Değişim oranı, tam kopyalar, kilit süreleri veya temizleme beklemeleri hesap dışı kalmış olabilir. | Politika bazında gerçek kullanım ve silinmeye uygun noktaları karşılaştırın. |
Kabul ve doğrulama kontrolleri
- İzin, context, servis ve veri tutarlılığını dosya sayısından ayrı doğrulayın.
- Seçilen kurtarma noktasını temiz bir hedefe geri yükleyin ve iş verilerini doğrulayın.
- Gözlenen veri kaybı penceresini hedef RPO ile karşılaştırın.
- Hazırlık, transfer, açılış ve iş onayını ayrı süreler olarak kaydedin.
- Üretim yönetim hesabı olmadan gerekli kurtarma erişimini test edin.
- Korunan kopyayı kontrollü silme denemesi ve gerçek restore ile sınayın.
İlgili kavramlar
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Dosya sistemi ve depolama katmanları
Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
RPO ve gerçek veri kaybı penceresi
RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.
RTO ve uçtan uca kurtarma süresi
RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Test süresinin hangi olayla başlayıp hangi olayla sona erdiğini açıkça belirtin. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.
Şifreleme ve anahtarın yaşam döngüsü
Şifreleme, verinin anahtar olmadan okunmasını zorlaştırır; erişim kontrolü, silinme koruması ve yedekleme farklı ihtiyaçları karşılar. Taşınan veri ile disk üzerindeki veri için hangi katmanın şifreleme sağladığını belirtin. Anahtarların oluşturulması, korunması, döndürülmesi ve acil geri kazanımı tasarımın parçasıdır. Yedeği kurtarmak için gereken anahtar yalnız felaket sırasında kaybedilecek sunucuda bulunmamalıdır. Test ortamında ayrı bir yöneticiyle veriyi açma ve anahtar erişimini geri kazanma adımlarını uygulayın; gerçek anahtarları dokümana veya destek mesajına koymayın.