Restic ve Borg ile S3 Uyumlu Uzak Yedekleme: Sürümleme, Şifreleme ve Saklama Ne Zaman, Nasıl?

Kahvemi Dökünce Aklıma Gelenler: Neden Uzak Yedek?

Hiç başınıza geldi mi? Benim bir sabah kahvemi klavyeye devirmemle başladı. Panikle değil, bir anlık tereddütle ekrana baktım. Dosyalarım güvende mi? Sunucuya bir şey olsa ya da yanlışlıkla bir klasörü silsem ne olur? O gün, sadece yerel yedeklerin yetmediğini, gönlün bir köşesinde uzak bir kasanın olması gerektiğini iyice hissettim. Ve açıkça söyleyeyim, o kasa çoğu zaman S3 uyumlu bir depoya işaret ediyor.

Bugün, Restic ve Borg ile S3 uyumlu uzak yedekleri nasıl kurgulayacağımızı, sürümleme mantığını nasıl oturtacağımızı, şifrelemeyi nasıl akıllıca ele alacağımızı ve saklama politikalarını hayata geçirirken izlenecek yolu konuşacağız. Konu teknik ama ben sohbet tadında anlatacağım. Mesela şöyle düşünün: bir zaman makineniz var ve dün geceki dosyaya geri dönmek istiyorsunuz. Sürümleme o zaman makinesi. Şifreleme, kasanın sağlam kilidi. Saklama politikası da depoyu şişirmeden, ihtiyaç duyduğunuz kopyaları elinizin altında tutma disiplini.

Aralarda günlük hayattan örnekler, ufak pratik komutlar ve küçük hatırlatmalar olacak. İçiniz rahat etsin; amacım karmaşık bir ormanı değil, gezmesi keyifli bir patikayı göstermek.

S3 Uyumlu Depo Ne Demek, Neden Rahat Hissettirir?

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 büyük taşınma operasyonları yerine ufak ayar değişiklikleriyle yolunuza devam edebilirsiniz.

Bir de şu var: Uzak bir depo demek, felaket anında farklı bir yerde duran bir can simidi demek. Aynı veri merkezinde duran iki kopya çoğu zaman tek kopya gibidir. Elektrik kesildi, depolama havuzu sıkıntı çıkardı, insan hatası bir klasörü uçurdu; uzak depo o anlarda sahneye girer. S3 uyumlu havuzun artısı, hem yatay büyümeye elverişli olması hem de istemci tarafında güzel bir akış kurgulayabilmeniz. Mesela erişim anahtarlarını döndürmek kolaydır, erişim kısıtlarını profillemek rahattır.

Tabii her çözümün bir bedeli var. Uzak depo internet üstünden geldiği için gecikme hissedilir; ilk tohumlama biraz uzun sürebilir. Ama doğru araçlarla deduplikasyon kullanırsanız, sonraki yedekler şaşırtıcı derecede hızlı akar. Restic burada kendi deduplikasyon büyüsüyle öne çıkıyor. Borg da blok düzeyinde işini iyi yapıyor. Önemli olan, sizin akışınıza en iyi uyan yolu bulmanız.

Restic ve Borg: Aynı Dilden Konuşan İki İyi Arkadaş

Şöyle bir gözünüzde canlandırın: Restic ve Borg, düzen takıntılı iki arkadaş. İkisi de değişmeyen blokları tekrar tekrar taşımaz, ikisi de veriyi şifreler ve doğrular, ikisi de sürümlerle çalışır. Dinamikleri farklıdır ama niyetleri aynı. Restic, S3 gibi nesne depolarla doğrudan konuşmayı sever; tek bir komutla S3 uyumlu bir havuza bağlanır. Borg ise kendini evinde hissetmek için daha çok dosya sistemi veya SSH üstünden ulaşılabilen bir uç nokta ister; nesne depoya doğrudan yazma konusunda resmi bir desteği yoktur, orada biraz yaratıcı çözümler devreye girer.

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 kullanıyorsanız çoğu kişi iki aşamalı işler: önce bir uzak VPS üstünde Borg deposu, sonra bu depoyu ayrı bir süreçle nesne depoya yansıtmak. Böylece Borg’un güçlü tutarlılık kontrolleri ve hızlı geri yükleme alışkanlıkları korunur, nesne depodan da ikinci bir güvenlik katmanı elde edersiniz. Bu düzeni anlatırken gözünüzde büyümesin; bir iki cron ve bir rclone senaryosu ile gayet akışkan hale gelir.

Sonuçta mesele birini diğerine üstün görmek değil; ihtiyacınıza göre en az sürtünmeyle çalışmak. Restic ile S3 üstünde tek atış bir kurulum, Borg ile SSH üstünden taş gibi bir depo ve arkadan çalışan bir yansıtma; ikisi de gayet hayat kurtarır.

S3 ile Tanışma Töreni: Anahtarlar, Bucket ve Uç Nokta

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 ile ilk depo başlatma hissi, boş bir defterin ilk sayfasını açmak gibi. Depoyu açıyor, ona bir parola veriyor, sonra da ilk anlık görüntüyü alıyorsunuz. Bir klişe gibi dursa da parolayı iyi seçmek ve bir şifre kasasında saklamak çok önemli. Katmanlı güvenlik, yedek dünyasında vazgeçilmez.

Borg tarafında doğrudan S3’e yazma olmadığını söyledik. Burada pratik bir yol, küçük bir VPS üzerinde Borg deposu kurmak ve depoyu periyodik olarak nesne depoya yansıtmak. Yani depolama ile taşıma işini birbirinden ayırıyorsunuz. Bu, veriyi geri dönerken de konfor sağlıyor; SSH ile Borg depoya bağlanıp hızlı bir geri yükleme alırken, nesne depodaki kopya size ekstra huzur veriyor. Yansıtma için rclone gibi araçlar gayet iş görüyor.

Sürümleme: Zaman Makinesini Akıllıca Ayarlamak

Sürümleme dendiğinde aklıma her zaman şu geliyor: Her yedek bir hikaye. Dünkü tamamlanmış iş, bugünkü küçük düzeltme, yarınki büyük değişiklik. Restic bu hikayeleri snapshot olarak saklıyor, Borg ise archive. Fikir aynı; her biri geçmişe açılan bir pencere. Asıl marifet, bu pencerelerin sayısını ve aralıklarını iyi yönetmek. Dümdüz her gün aynı saatte almak yetmez; neyi, ne kadar süre tutacağınızı kurgulamak önemli.

Restic tarafında unutma ve budama için ince ayarlar var. Mesela günlük son 7 kopya, haftalık son 4, aylık son 12 gibi bir düzen. 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. Benim sevdiğim yaklaşım, önce cömert davranıp beklediğim geri dönüşlere göre birkaç hafta boyunca gözlem yapmak, sonra da adım adım sıkılaştırmak. İlk başta geniş ağ atmak, sonra ağın gözlerini daraltmak gibi düşünebilirsiniz.

Sürümlemede adlandırma da işin görünmeyen kahramanı. Restic’te etiketlerle (tag) bir görevi ya da projeyi işaretlemek, Borg’ta arşiv adlarında tarih ve makine bilgisini barındırmak, geri dönüş anında dakikalar kazandırır. Küçük bir pratik: Üretim, test ve kişisel dizinler için farklı etiketler kullanın; erişmek istediğiniz anı bulmak çok daha hızlı olur.

Şifreleme: Kasanın Kilidini Nasıl Sağlam Tutarsınız?

Yedek kasasına koyduğunuz her şeyin gizli kalması gerekiyor. Restic ve Borg bu konuda cimri, güzeli de o. Varsayılan olarak uçtan uca şifreleme var ve şifreleme anahtarları depo içinde yönetiliyor. Sizin göreviniz, o parolayı ve gerekirse anahtar dosyalarını güvenli bir yerde saklamak. Şifre kasası kullanmak burada hayat kurtarıyor. Biraz daha ileri giderim diyorsanız, parolayı döngüsel olarak yenilemek ve erişimleri iki kişiden fazlasına açmamak iyi bir pratik.

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

Bazı ekipler, istemci tarafı şifreleme zaten varken, sunucu tarafı şifrelemeyi de açıyor. Çifte kilit gibi düşünebilirsiniz. Yönetimi biraz daha karmaşık hale getirebilir ama ayrışmış yetkiler ve politika gereksinimleri olan yerlerde anlamlıdır. Asıl mesele, kurtarma anında parolayı ve anahtarları bulabilecek bir düzen kurmak. Anahtarlar yoksa yedek de yok demektir; bunu ekip içi eğitimlerde özellikle vurgulamak iyi olur.

Saklama Politikaları: Uçmayan, Şişmeyen, Tam Yerinde Bir Plan

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.

Pratik bir başlangıç, günlük/haftalık/aylık şemasını kurmaktır. Her gün birkaç kopya, haftada bir toplu görüntü, ayda bir uzun ömürlü arşiv. Bir süre izleyin; depo ne kadar büyüyor, geri dönüşler nereden geliyor. Bazen, ilk ay cömert bir şema kurup ikinci ay sadeleştirmek iyi sonuç verir. Bu sayede hem maliyeti hem de depolama büyümesini gözle görürsünüz.

Bu arada, yedeklenen verinin türüne göre özel politikalar eklemek de mümkün. Veritabanları için daha sık ve kısa ömürlü kopyalar; dosya sunucuları için daha seyrek ama uzun ömürlü kopyalar akışkan bir denge kurar. Eğer veritabanı tarafında detaylara dalmak isterseniz, MySQL/MariaDB yedekleme stratejileri ve point‑in‑time recovery üzerine notlar hoş bir yoldaş olabilir.

Uzak depolarla çalışırken maliyeti kontrol etmenin güzel yolu, deduplikasyonun hakkını vermek ve gereksiz dosyaları yedek dışına almak. Node_modules klasörleri, cache dizinleri, geçici render çıktılarını yedeklemek yerine gerektiğinde yeniden üretmek çoğu zaman daha mantıklı. Her bir hariç tutma satırı, depoda birkaç gigabaytın veda etmesi demek olabilir.

Akışın Ritmi: Otomasyon, Sağlık Kontrolleri ve Alarm

Günün sonunda yedekleme, unutmayı gerektiren bir iş olmalı; kur, ayarla, takip et ve kendi kendine aksın. Cron ile belirli saatlerde çalışan yedek görevleri, ardından bir check adımı, sonra küçük bir rapor. E‑posta ile gelen kısa bir özet, her şey yolunda der ve siz gününüze devam edersiniz. Arada bir kasıtlı geri yükleme provası, kas hafızasını diri tutar. Bir bakıma yangın tatbikatı gibi; gerektiğinde ne yapacağınızı parmaklarınız bilir.

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, başarısız bir yedeği dashboard’da kırmızı bir kart olarak görmek ve anında bildirim almak iç ferahlatır.

Doğrulama deyince Restic ve Borg’un kendi check komutları güzel bir alışkanlık kazandırır. Haftada bir bütünlük kontrolü, ayda bir geniş kapsamlı doğrulama, depoyu sağlıklı tutar. Eskimiş kilit dosyalarını temizlemek, yarım kalmış yedekleri toparlamak ve erişim anahtarlarını yenilemek de ritmin bir parçası. Düzenli işleyen bir küçük bakım listesi, büyük sorunları hiç doğmadan söndürür.

Performansın İnce Ayarları: İlk Tohumlama, Artımlı Akış ve Küçük Sırlar

İlk yedek her zaman en büyüğüdür, bunu kabullenince gerisi kolay. 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. Bazı ekipler ofisteki MinIO’ya yazıp geceleri bulut havuza replikasyon yapıyor; gündüz performanslı, gece sessiz bir akış. Restic’in artımlı yedekleri bu senaryoda parlıyor; ilk kopyadan sonra sadece farkların akması iç ısıtıyor.

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. Depoyu nesne depoya yansıtacaksanız, rclone’un artımlı kopyalama ve doğrulama seçeneklerini nazikçe ayarlamak gerekir. Bu yansıtma işini geceleri çalıştırmak, gündüz kullanıcılarının nefesini kesmeden işinizi yapmanızı sağlar.

Politikalarla Uyum: Erişim, Log ve Küçük Notlar

Yedekler sadece teknoloji değil, biraz da kültür. Kim erişir, ne zaman erişir, erişince ne yapar. S3 tarafında erişim politikalarını profil bazlı tutmak, yedekleme hesabına depo yazma izni vermek ama silmeyi sınırlamak bazen ciddi kazaların önüne geçer. Nesne depoda versiyonlamayı açmak, istemci tarafı sürümlemeye ek bir ağ gibi düşünebilirsiniz; yanlışlıkla silinen bir nesnenin önceki versiyonuna dönmek bazen hayat kurtarır.

Log tutmak da önemli. Yedekler başladı mı, bitti mi, kaç dosya atlandı, kaç hata alındı. Bu günlükleri sadece tutmak değil, okunabilir kılmak lazım. Birkaç satırla başlayan özetler, bir bakışta sorun olup olmadığını gösterir. Detaya dalmak isterseniz gerisi zaten logda durur.

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. Ben çoğu zaman bu değişkenleri ortam dosyalarında tutup betikleri standardize ediyorum. Böylece uç nokta, anahtarlar, bucket adı değişse bile, yedek akışı yerinden oynamıyor. 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

Yedek, geri dönmeyi bildiği kadar değerlidir. Bu yüzden düzenli aralıklarla mini kurtarma provaları yapmak bence şart. Bir dosyayı farklı bir klasöre geri getirmek, bir proje dizinini yeni bir makineye çekmek, hatta bazen bir veritabanını geçici bir sunucuya ayaklandırmak. Bu alıştırmalar, gerçek bir aksilikte nefes aldırır. Sürprizlere hazırlıklı olmak, paniğin sesini kısar.

Restic’te listeler, etiketler ve tarih aralığıyla arama yapmak elinizi hızlandırır. Borg’ta arşiv taramaları ve dosya bazlı geri yükleme aynı şekilde. Her iki tarafta da tek bir komutla, üstelik şifreli depodan, hedefe güvenle akmak büyük keyif. Bu noktada küçük ama altın bir kural: Geri yükleme hedefi asla orijinal dizininiz olmasın. Yanlış tuşla üstüne yazmak istemezsiniz; önce ayrı bir köşeye indirip gözünüzle kontrol edin.

Kurtarma provaları bittiğinde kısa bir not bırakmayı da seviyorum. Ne kadar sürdü, nerede takıldım, bir dahaki sefere neyi değiştirmeliyim. Bu küçük günlük, gelecekteki ben’e yazılmış bir mektup gibi. Sakin ve yararlı.

Ek Notlar: Komutlar, İpuçları ve Ufak Uyarılar

Çok teknikleşmeden birkaç tatlı not düşeyim. Restic’te ilk depo açarken, parolanızı yazıp doğruladıktan sonra küçük bir test yedeği alın ve hemen ardından bir check çalıştırın. Depoya güven hissettirin. S3 uç noktasıyla konuşurken saat ve bölge ayarlarının doğru olduğuna dikkat edin; bazı imzalama akışları saat sapmasına hassas davranır. Borg tarafında ise uzak uçla SSH anahtarını sağlamlaştırın; parola yerine anahtar ve mümkünse forced command kullanmak hoş bir güvenlik refleksi.

Yedek dışında kalması gereken dizinleri baştan netleştirmek de önemli. Geçici klasörler, yeniden üretilebilir derleme çıktıları, sürekli değişen ama değeri sınırlı loglar. Bu alanları hariç tutunca yedek akışı hızlanır, depo büyümesi daha öngörülebilir olur. Belli aralıklarla hariç tutma listesini gözden geçirmek, projeler değiştikçe güncellemek gerekir.

Son olarak, belgeleme. Basit bir okuma dosyası, bir şema, birkaç başlık. Kim, neyi, nereye, nasıl yedekliyor ve nasıl geri dönecek. Üç ay sonra yeni bir ekip arkadaşı geldiğinde bu dosya altın değerinde olur. Unutmayın, yedekleme aslında bir takım sporu.

Kapanış: Yarını Rahatlatan Bugünün Küçük Adımları

Buraya kadar geldiyseniz, bence zihninizde güzel bir resim oluştu. S3 uyumlu bir uzak depo, Restic veya Borg ile düzenli çalışan bir akış, akıllıca kurgulanmış sürümleme, sağlam bir şifreleme ve ayakları yere basan saklama politikaları. Bunların hepsi bir araya geldiğinde, gece rahat uyumayı sağlayan bir güvenlik ağı oluşuyor. Bir sorun olduğunda, paniğe değil prosedüre sarılıyorsunuz. İşte amaç tam da bu.

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. Bir hafta sonra unutma/budama kurallarını ekleyin, bir ay sonra mini bir kurtarma provası yapın. İzlemeyi kurun, küçük alarmlar ekleyin. Parolaları ve anahtarları güvenli bir kasaya koymayı ihmal etmeyin. Geliştikçe, otomasyon betiklerini sadeleştirin. Bir noktada akış kendi kendine yürümeye başlayacak.

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. Bizim tarafta ağ ve uygulama katmanında neler yaptığımızı merak ederseniz, WAF ve bot korumasını aynı masada barıştırdığımız hikayeyi keyifle okuyabilirsiniz. Yedekler de bu masanın bir üyesi. Umarım bu yazı size bir başlangıç cesareti ve pratik bir çerçeve vermiştir. Bir dahaki yazıda görüşmek üzere; dosyalarınız hep güvende kalsın.