Kurulum · Depolama ve Yedekleme

Restic ve S3 Uyumlu Depolama ile Yedekleme Pilotu

Restic kaynak dosyaları şifreli repository yapısında saklar. S3 backend’i Amazon S3 veya uyumlu servise bağlanabilir; diğer servislerde API uyumu ve davranış ayrıca test edilir. NAS…

Teknik gözden geçirme: 2026-10-06

Mimari ve çalışma modeli

Restic kaynak dosyaları şifreli repository yapısında saklar. S3 backend’i Amazon S3 veya uyumlu servise bağlanabilir; diğer servislerde API uyumu ve davranış ayrıca test edilir. NAS üzerinde SMB/NFS dosya yedeği ve uygulama tutarlılığı aynı problem değildir; açık veritabanı dosyalarını kör dosya kopyasıyla yedeklemeyin.

Önce ayrı bucket, sınırlı erişim kimliği ve repository parolasını oluşturun. Parolayı kaynak makineden bağımsız kurtarma kasasında saklayın. init, backup, snapshots, check ve restore zincirini küçük bir test dizininde tamamlayın. Saklama ve prune işlemlerini kabulden sonra ekleyin.

Object Lock ile repository kilidi farklıdır. Restic metadata değişimi ve prune akışı seçilen immutable ayarla çakışabilir. Bucket policy veya retention değişikliğini üretimde denemek yerine sürüm ve backend ile pilotta doğrulayın; şifreli yedek anahtar kaybolursa kurtarılamaz.

1Tutarlı kaynak
2Restic şifreli repository
3S3 saklama
4Ayrı ortamda restore

Sırları güvenli ortamdan sağlayın.

Tasarım parametreleri

Erişim kimliği: Bucket ve gerekli repository yollarıyla sınırlayın; anahtarları komut geçmişine koymayın.
Tutarlılık: Dosya paylaşımı snapshot’ı veya uygulama export işlemini yedek öncesinde planlayın.
Doğrulama: Metadata check ile tüm veriyi okuyan kontrolün süre/maliyet farkını ölçün.

Hesap ve uygulama örneği

10 GB test verisini yedekleyin ve ayrı bir makinede farklı dizine restore edin. Dosya sayısı ve SHA-256 değerleri eşleşmeli; dosya izinleri ve uygulama açılışı da sınanmalıdır. Yalnız başarılı backup çıkış kodu, kurtarma kabulü değildir.

Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.

export RESTIC_REPOSITORY="s3:https://s3.example.test/doz-backup"
# Supply RESTIC_PASSWORD and backend credentials through an approved secret store.
restic init
restic backup /srv/lab-data
restic snapshots
restic check
restic restore latest --target /srv/lab-restore

Hata teşhisi

Belirti	Olası neden / ayrım	Doğrulama
AccessDenied	Bucket policy veya kimlik kapsamı.	Başarısız API işlemini ve hedef prefix’i logdan inceleyin.
Backup var, restore anahtarı yok	Repository parolası yalnız kaynakta saklanmış.	Bağımsız parola kurtarma prosedürünü pilotta sınayın.

Kabul ve doğrulama kontrolleri

Sırları güvenli ortamdan sağlayın.
Küçük test repository’si oluşturun.
Kaynak tutarlılığını doğrulayın.
Check çıktısını inceleyin.
Ayrı makinede restore yapın.
Retention/prune uyumunu sınayın.

İlgili kavramlar

Ş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.

Saklama politikası ve kapasite

Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.

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 ACLleri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.

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. Bir testin kronometresini hangi olayda başlatıp bitirdiğinizi açıkça yazın. 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.

Kalıcılaştırma ve güç kaybı

Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.

Birincil teknik dokümantasyon

Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.

Bilgi Merkezi