Neden Ayrı Bir Uzak Yedek Gerekir?
Sunucu arızası, yanlış silme veya ele geçirilmiş bir yönetim hesabı, aynı sistemdeki yedekleri de etkileyebilir. Farklı bir hata alanında bulunan ve kurtarılması denenmiş uzak kopya bu riski azaltır. S3 uyumlu depolama bu amaçla kullanılabilir; ancak uzakta olması tek başına silinmeye karşı koruma veya başarılı geri yükleme garantisi değildir.
Bu kavramsal rehber iki mimariyi karşılaştırır: Restic ile doğrudan S3 deposu ve Borg 1.x ile SSH deposunun S3’e tutarlı kopyalanması. Sürüm saklama, şifreleme, erişim ve kurtarma kararlarını ele alır. Borg bakım akışı 1.2 veya sonraki uyumlu 1.x istemci/sunucu sürümlerini esas alır; sürüm 2 için aynı komut ve depo varsayımlarını kullanmayın.
Önce kabul edilebilir veri kaybını ve hizmetin yeniden açılması için gereken süreyi belirleyin. Sonra hangi verinin, hangi sıklıkta ve hangi bağımsız konuma yedekleneceğini seçin. Buradaki karar çerçevesini, kurulu araç sürümünün belgeleriyle uygulamaya dönüştürün.
S3 Uyumluluğu ve Hata Alanı
S3 uyumlu dediğimizde kastettiğimiz şey şu: veriyi depolayan servis, S3 API dilini konuşuyor. Yani Restic gibi yedek araçları bu depoya sanki klasik bir S3 gibi bağlanabiliyor. Bu depolar bazen bulutta bir servis, bazen de ofiste çalışan bir MinIO kurulumu olabiliyor. İyi hissettiren tarafı, jenerik bir dil konuştuğu için daha az kilitlenirsiniz; servis değiştirmeniz gerekirse bağlantı ayarlarını uyarlamak kolaylaşabilir; ancak mevcut yedekleri taşımak veri aktarımı, maliyet ve uyumluluk kontrolü gerektirir.
Aynı veri merkezindeki iki kopya bazı donanım arızalarına karşı yararlıdır, ancak tesis çapındaki riski paylaşabilir. Uzak konumu seçerken sağlayıcı, bölge, hesap ve erişim bağımlılıklarını değerlendirin. Kaynak sunucudaki kimlik bilgileri uzak kopyaları da silebiliyorsa, sunucunun ele geçirilmesi bu kopyayı etkileyebilir. S3 API uyumluluğu, sağlayıcıların dayanıklılık, sürümleme ve kilitleme özelliklerinin aynı olduğu anlamına gelmez.
İlk aktarım büyük olabilir; sonraki aktarımın boyutu veri değişimine ve deduplikasyona bağlıdır. Sık değişen büyük dosyalar yine önemli trafik oluşturabilir. İlk yükleme, günlük aktarım, bütünlük kontrolü ve tam geri yüklemenin bant genişliği ile maliyetini ayrı ölçün.
Restic ve Borg İçin İki Ayrı Akış
Restic snapshot, Borg archive kavramlarını kullanır. İkisi de deduplikasyon sağlar; Restic veriyi istemcide şifreler, Borg’ta şifreleme depo oluşturulurken seçilen moda bağlıdır. Restic S3 arka ucunu doğrudan destekler. Bu rehberdeki Borg 1.x akışı ise yerel dosya sistemi veya SSH deposuna dayanır; S3 kopyası ayrı bir aktarım işlemidir.
Günlük rutinde şu pratik ayrım kafayı rahatlatır: S3 gibi bir depoya doğrudan yazmak istiyorsanız Restic işleri kolaylaştırır. Borg 1.x için bir seçenek iki aşamalı çalışmaktır: önce bir uzak VPS üstünde Borg deposu, sonra bu depoyu ayrı bir süreçle nesne depoya yansıtmak. Bu, iki ayrı bakım ve kurtarma yolunun yönetilmesini gerektirir. Yansıtma sırasında depoya yazan işlemleri durdurun veya tutarlı bir dosya sistemi anlık görüntüsünü kopyalayın; canlı deponun dosyalarını gelişigüzel eşitlemek tutarsız bir kopya oluşturabilir. Silmeleri de yansıtan bir eşitleme, bağımsız sürüm saklama olmadan eski kopyaları korumaz.
Borg’un resmi rehberi bağımsız yedek depoları için ayrı başlatılmış depoları önerir. Depoyu dosya düzeyinde kopyalarsanız kopya aynı depo kimliğini taşır; iki kopyayı bağımsız yazılabilir depo gibi kullanmayın. Bu rehberdeki S3 yansısı, denetimli kurtarma için pasif kopyadır. Hasar ve silme yansıtılabileceği için önceki kurtarılabilir nesil ayrıca korunmalıdır.
Depo, Erişim Anahtarı ve Parola Hazırlığı
Mesela şöyle düşünün: Kapıda bir güvenlik var ve içeri girmek için iki anahtara ihtiyacınız var. S3 dünyasında bunlar genellikle erişim anahtarı (access key) ve gizli anahtar (secret key). Bir de kime gideceğinizi söylemeniz gerek, yani uç nokta (endpoint). Restic cephesinde olay basit; ortam değişkenlerine anahtarları koyarsınız, URL’de de hedefi işaret edersiniz. Örneğin bir MinIO kurulumu kullanıyorsanız, uç nokta genellikle ofisinizdeki ya da VPS’inizdeki adres olur. Bu arada, MinIO ile kendi S3 uyumlu havuzunuzu kurmak istiyorsanız MinIO belgeleri üzerinden kurulum akışını gözden geçirmek iyi bir başlangıç sunar.
Restic için depo URL’si, gerekiyorsa bölge ve oturum belirteci, erişim yetkileri ve depo parolasını hazırlayın. Gerçek sırları komut geçmişine veya sürüm kontrolüne yazmayın; erişimi sınırlı parola dosyası veya sır yönetimi kullanılabilir. Depoyu yalnız ilk kurulumda başlatın. Parolayı ve kurtarma bilgilerini yalnız yedeklenen sunucuda bırakmayın; küçük bir yedek ve ayrı hedefe geri yükleme ile erişimi doğrulayın.
Borg 1.x deposunun nesne depodaki kopyasından kurtarma, SSH ile hazır depoya bağlanmaktan farklıdır: önce tutarlı depo kopyasını bir dosya sistemine geri alın, ardından Borg ile bütünlük kontrolü ve dosya geri yüklemesi yapın. Bu ek aktarımın süresini kurtarma planına dahil edin.
Snapshot, Arşiv ve Saklama Kapsamı
Snapshot veya arşiv, seçilen verinin geri yüklenebilir bir sürümünü temsil eder; değişen tüm dosya sisteminin aynı anda alınmış atomik görüntüsü olduğu varsayılmamalıdır. Bir dosya aramak, bir uygulamayı çalışır hâle getirmek ve tam sunucu kurtarmak farklı ihtiyaçlardır. Saklama aralığını ve yedek kapsamını bu ihtiyaçlara göre belirleyin.
Restic tarafında unutma ve budama için ince ayarlar var. Mesela yedek bulunan son 7 günün, 4 haftanın ve 12 ayın her birinden birer anlık görüntü tutmak gibi bir düzen; aynı görüntü birden fazla kuralı karşılayabilir. Bu akışı kurgularken Restic’in unutma ve budama anlatımı çok yalın bir yol haritası verir. Gerçekte ise matematiği küçük küçük denemelerle oturtmak gerekir. Veri setinizin boyutu, değişim sıklığı ve geri dönüş beklentiniz bu denklemi belirler.
Borg cephesinde de prune ile benzer bir disiplin kurarsınız. Günlükleri, haftalıkları, aylıkları nasıl dengelediğiniz, depo büyüklüğü ile maliyeti belirler. Borg’un prune rehberi basit ama güçlü bir çerçeve sunar. Önce kuru çalıştırmada korunacak ve silinecek arşivleri inceleyin. Borg budaması varsayılan olarak depodaki tüm arşivleri kapsar; paylaşılmış depoda doğru arşiv filtresi gerekir. 1.2 ve sonrasında fiziksel alanı geri kazanmak ayrı compact adımıdır.
Restic etiketleri ve Borg arşiv adları görevleri ayırt etmeye yarar. Restic 0.18’de forget varsayılan gruplaması host ve paths’tir; etiketlere göre gruplama veya filtreleme ayrıca seçilir. Makine, yol veya etiket düzenini değiştirirken mevcut saklama kuralının kapsamını yeniden kontrol edin. Farklı veri kümelerinin aynı politika altında istemeden silinmemesi gerekir.
Şifreleme ve Kurtarma Anahtarları
Restic veriyi istemcide şifreler; Borg’ta şifreleme depo oluşturulurken seçilen moda bağlıdır. Restic’in parola korumalı anahtarları depoda tutulur; Borg’ta anahtarın yeri kullanılan anahtar moduna bağlıdır. Sizin göreviniz, o parolayı ve gerekirse anahtar dosyalarını güvenli bir yerde saklamak. Borg repokey modunda parola korumalı anahtar depodadır; ayrıca güvenli anahtar dışa aktarımı saklayın. Erişimleri görev gereksinimine göre sınırlandırın. Parola değişikliği veri şifreleme anahtarını otomatik olarak değiştirmez; sızıntı şüphesinde anahtarın da etkilenip etkilenmediğini değerlendirin.
Şifreleme sadece depoda duran kopya için değil, yolculuk için de önemli. S3 uyumlu servisle konuşurken bağlantının TLS üstünden kurulduğunu ve sertifikaların düzgün çalıştığını kontrol etmek gerekir. İçeride her şey şifreli olsa da yolda sniff eden bir gözün bağlantınızı okuyamaması gönül rahatlığı sağlar. MinIO gibi kendi kurulumlarınızda, sertifika işini baştan sıkı tutmak sonraki tüm süreçleri kolaylaştırır.
Sunucu tarafı şifreleme, istemci şifrelemesinden ayrı bir yönetim katmanıdır. Kullanılıyorsa sağlayıcı anahtarları, hesap erişimi ve kurtarma bağımlılıkları da plana yazılmalıdır. Parola, depo anahtarı ve S3 erişim anahtarı aynı şey değildir. Birini değiştirmek diğerini otomatik yenilemez; kurtarma provasını gerekli tüm sırlarla birlikte yapın.
Veri Türüne Göre Saklama Politikası
Saklama politikası kulağa resmi bir prosedür gibi gelebilir ama aslında çok insani. Asıl soru şu: Hangi zaman diliminden geri dönmek istersiniz ve bu kopyaları nerede, ne kadar süre saklamak ekonomiktir? Kimi ekip için son 30 gün önemlidir, kimi için yıllık arşivler. Bazıları dosya bazlı dönüş ister, bazıları tam sistem kurtarma. O yüzden tek bir doğru yok; sizin gerçek akışınıza uyan doğru var.
Yedek sıklığı ile saklama süresini ayrı belirleyin. Saatlik yedek almak her kopyayı yıllarca saklamayı gerektirmez; aylık kopya saklamak da ara günlerdeki değişiklikleri geri getirmez. Politikanın seçtiği gerçek kopyaları kuru çalıştırmada inceleyin ve bütçeyi ölçülmüş veri büyümesine göre ayarlayın.
Bu arada, yedeklenen verinin türüne göre özel politikalar eklemek de mümkün. Canlı veritabanı dosyalarını doğrudan Restic/Borg ile kopyalamak uygulama açısından tutarlı yedek sağlamayabilir. Önce veritabanının desteklediği tutarlı döküm, fiziksel yedekleme veya koordineli anlık görüntü yöntemini kullanın; işlemin başarıyla bittiğini doğrulayın. Ardından tamamlanmış yedeği aktarın. Yedek sıklığı ve saklama süresi verinin değişimiyle kurtarma ihtiyacına bağlıdır. Eğer veritabanı tarafında detaylara dalmak isterseniz, MySQL/MariaDB yedekleme stratejileri ve point‑in‑time recovery üzerine notlar hoş bir yoldaş olabilir.
Yalnız yeniden üretilebildiği doğrulanmış önbellek ve geçici çıktıları hariç tutun. Paket kilit dosyaları, yapılandırmalar, kullanıcı yüklemeleri ve kurtarma için gereken günlükler aynı kategoride değildir. Bir dizini çıkarmadan önce geri yükleme sırasında onu hangi kaynak ve sürümle oluşturacağınızı test edin.
Akışın Ritmi: Otomasyon, Sağlık Kontrolleri ve Alarm
Zamanlayıcı yalnız görevi başlatır; başarıyı veya işlemlerin doğru sırada bittiğini garanti etmez. Yedekleme, budama, compact ve dış kopyalama işlemlerini koordine edin. Başarılı ve yeterli kapsamlı bir yedek doğrulanmadan eski nesilleri otomatik silmeyin. Hem hata hem de beklenen sürede yeni başarılı yedek oluşmaması için alarm üretin.
Eğer izlemenin tadını almak istiyorsanız, yedekleme başarı/başarısızlık işaretlerini basit bir webhook ya da export ile izleme sisteminize göndermek güzel olur. Mesela Prometheus, Grafana ve Node Exporter ile sessiz alarmları konuşturmak gibi bir akış kurarsanız, son başarılı yedeğin yaşını, işlem sonuçlarını ve kopyalamanın tamamlandığını takip edebilirsiniz. Alarm iletimini de sınayın.
Doğrulama deyince Restic ve Borg’un kendi check komutları güzel bir alışkanlık kazandırır. Haftalık bütünlük kontrolleri sorunları saptamaya yardımcı olur; tüm yedek verisini okuyan doğrulama ayrıca planlanmalıdır. Kilitleri yalnızca ilgili işlemin artık çalışmadığını doğruladıktan sonra kaldırın. Yarım kalmış işleri incelemek ve erişim anahtarlarını yenilemek de bakımın parçasıdır; kontroller tek başına bozulmayı önlemez.
Aktarım, İşlemci ve Depolama Maliyeti
İlk yedek genellikle büyüktür; sonraki büyük veri değişiklikleri daha büyük yedekler oluşturabilir. Eğer bant genişliği sınırlıysa, ilk tohumlamayı lokal bir hedefe alıp sonra bu kopyayı buluta taşımak mantıklı olabilir. Örneğin ofisteki MinIO’ya yazıp geceleri buluta kopyalamak düşünülebilir. Ancak ilk yüklemenin aktarım hacmi azalmaz; kopyalama sırasında depo değişmemeli veya tutarlı bir depolama anlık görüntüsü kullanılmalıdır. Restic sonraki yedeklerde depoda bulunmayan veri parçalarını ve yeni metaveriyi aktarır.
Disk hızı ve CPU da bu oyunda önemli. Sıkıştırma ve şifreleme işlemciyi, deduplikasyon disk I/O’yu konuşmaya zorlar. Kaynakların yerinde seçimi performansı ciddi etkiler. Eğer bu taraflara ilgi duyuyorsanız, NVMe VPS hızının nereden geldiğini ve pratikte neye dönüştüğünü okumak, yedek akışınızdaki dar boğazları sezmenize yardım eder.
Borg’u SSH üstünden kullanıyorsanız, uzak uçta küçük bir VPS’iniz olsun, bellek ve disk I/O’su yeterli kalsın. Bu rehberdeki Borg 1.x doğrudan S3 deposu kullanmaz. Depoyu rclone ile nesne depoya kopyalayacaksanız, yazma ve bakım işlemlerini durdurun veya tutarlı bir depolama anlık görüntüsünü kopyalayın. Kurtarmada depoyu önce Borg’un erişebildiği bir dosya sistemine geri alın ve doğrulayın. Gece çalıştırmak çakışmayı azaltabilir; kaynak tüketimini veya sağlayıcı aktarım ücretini kendiliğinden düşürmez.
Erişim Yetkileri ve Nesne Sürümleme
S3 tarafında yetkileri görev bazında ayırmak kazaları sınırlayabilir. Restic’in normal işleyişinde okuma, listeleme, yazma ve kilit nesnelerini silme izinleri gerekir; genel bir silme yasağı kilit temizliğini engelleyebilir. Saklama temizliği için gereken silme yetkilerini ayrıca planlayın. Nesne depoda versiyonlamayı açmak, istemci tarafı sürümlemeye ek bir ağ gibi düşünebilirsiniz; Yanlışlıkla silinen nesneler sürüm geçmişinden kurtarılabilir; ancak depo kurtarmada tek bir nesneyi döndürmek yetmeyebilir. Gerekli nesneleri birbiriyle tutarlı bir duruma getirip depoyu doğrulamak gerekir. Sürümleme tek başına değişmezlik değildir. Object Lock destekleniyorsa belirli nesne sürümlerini korur; normal silme işaretleri ve yeni sürümler yine oluşabilir. Yetki, kilit modu ve yaşam döngüsünü araçla birlikte test edin.
Başlama/bitiş zamanı, son başarılı yedek, okunamayan dosyalar, veri büyümesi ve bakım sonuçlarını kaydedin. Bir komutun çıktı üretmesi başarısı anlamına gelmez; çıkış durumu ve kapsam birlikte değerlendirilmelidir. Depoda yeni bir snapshot bulunması, uygulamanın kurtarılabildiğini tek başına göstermez.
Bulutla kurduğunuz ilişkinin esnek kalması için, servis değiştirmeniz gerekirse minimum yeniden yapılandırmayla devam edebileceğiniz bir soyutlama katmanı kurmak iyi olur. Bu değişkenleri erişimi kısıtlı ortam dosyalarında tutup betikleri standardize edebilirsiniz. Böylece uç nokta, anahtarlar ve bucket adı değiştiğinde uyarlama kolaylaşır; yeni sağlayıcının uyumluluğunu ve taşınan depodan kurtarmayı yine de doğrulamak gerekir. Daha geniş bir bakış için bulut entegrasyon trendlerine nasıl uyumlanabileceğinizi gözden geçirmek fikir açar.
Kurtarma: Küçük Provalar, Büyük Güven
Önce ayrı ve boş bir hedefe dosya veya dizin geri yükleyin; içerik, izin, sahiplik ve gereken genişletilmiş öznitelikleri kontrol edin. Veritabanı provasını tamamlanmış tutarlı yedekten ayrı test hizmetine yapın. Daha büyük bir tatbikatta DNS, sırlar, bağımlılıklar ve hizmetin açılmasını da sınayın. Küçük dosya testi tam sistemin kurtarma süresini kanıtlamaz.
Restic’te doğru snapshot kimliğini seçip ayrı hedefe geri yükleyin. Borg 1.x SSH deposu kullanılabiliyorsa ilgili arşivden dosyaları çıkarabilirsiniz; yalnız S3 yansısı kaldıysa önce bütün ve tutarlı depo kopyasını dosya sistemine indirmek gerekir. Kopyayı izole kurtarma ortamında doğrulayın, sonra seçilen arşivi boş hedef dizinde açın. Kaynak depo ile kopyayı bağımsız etkin depolar gibi güncellemeyin; eski kopya için çıkan güvenlik uyarılarını körlemesine bastırmayın.
Kurtarma provaları bittiğinde kısa bir not bırakın: Ne kadar sürdü, nerede takıldınız, bir dahaki sefere neyi değiştirmelisiniz? Bu küçük günlük, sonraki kurtarma için sakin ve yararlı bir rehber olabilir.
Uygulamaya Geçmeden Önce Kontrol Edilecekler
Restic deposunun erişimini, TLS doğrulamasını, bölgesini ve saat gereksinimlerini sınayın. Borg SSH erişiminde sunucu kimliğini doğrulayın ve anahtar yetkisini gereken depo işlemleriyle sınırlandırın; forced command kullanılıyorsa bakım ve kurtarmaya da izin veren kapsamı ayrıca test edin. Check, veri doğrulaması ve uygulama geri yüklemesi farklı kontrollerdir.
Belli aralıklarla hariç tutma listesini gözden geçirmek, projeler değiştikçe güncellemek gerekir.
İşletim kaydında veri kaynakları, sürümler, hariç tutmalar, tutarlılık hazırlığı, sırların yeri, saklama kapsamı ve iki aşamalı Borg kurtarması yer alsın. Kopyalamayı hangi makinenin çalıştırdığı ve yazıcıların nasıl durdurulduğu açıkça belirtilsin. Bu kaydı yalnız kaybedilebilecek kaynak sunucuda tutmayın.
Yedekleme Planını Doğrulayarak Genişletin
Restic’in doğrudan S3 yolu daha az aktarım aşaması içerir. Borg 1.x ve S3 yansısı, mevcut Borg kullanımını koruyabilir ancak tutarlı kopyalama ve ek kurtarma süresi gerektirir. Kararı, araç tercihi kadar ölçülen kurtarma süresi ve yönetilebilen bağımlılıklar belirlemelidir.
Pratik tavsiyem şu: Küçük başlayın ama sıkı başlayın. Bugün tek bir klasörü yedekleyin, yarın kapsamı büyütün. Önce bu yedekten mini bir kurtarma provası yapın; ardından unutma/budama kurallarını, korunacak kopyaları gözden geçirerek ekleyin. İzlemeyi kurun, küçük alarmlar ekleyin. Parolaları ve anahtarları güvenli bir kasaya koymayı ihmal etmeyin. Geliştikçe, otomasyon betiklerini sadeleştirin. Kapsam ve sağlayıcı değiştikçe aynı doğrulamaları tekrarlayın.
Eğer bu yolculuğu bulut altyapınızla el ele götürmek istiyorsanız, S3 uyumlu depolarla beraber güvenlik cephesini de düşünmek akıllıca olur. Ağ ve uygulama katmanındaki koruma seçeneklerini merak ederseniz, WAF ve bot korumasını birlikte ele alan yazıyı okuyabilirsiniz. Ağ koruması yedeklerin yerine geçmez; kurtarma planı da kaynak sistemin bakım ihtiyacını ortadan kaldırmaz.
