restic ile Şirket Yedeklemesi 2026: Şifreleme, Append-Only, Saklama ve Denetim

Şirket verisini yedeklemek kadar, o yedeğin fidye yazılımından, yanlışlıkla silinmekten ve depolama sağlayıcısının meraklı gözünden korunması da önemlidir. restic, sunucu ve bilgisayarların yedeğini şifreli, tekilleştirilmiş (aynı veriyi bir kez saklayan) ve hızlı biçimde almak için kullanılan, BSD-2 lisanslı açık kaynak bir komut satırı aracıdır. Bu rehberde restic'in nasıl çalıştığını, nerelere yedek alabildiğini, fidye yazılımına karşı "yalnız ekleme" (append-only) kurulumunu ve düzenli bakım komutlarını resmi belgelere dayanarak (Ekim 2026, restic 0.19.1) anlatıyoruz. Genel yedekleme stratejisi için önce 3-2-1-1-0 kuralını anlattığımız rehberimize bakabilirsiniz.

restic nasıl çalışır?

• Şifreleme: belgelere göre depoya yazılan tüm veri AES-256 (sayaç modu) ile şifrelenir ve Poly1305-AES ile doğrulanır. Depolama sağlayıcısı ya da sunucu yöneticisi yedeğin içeriğini okuyamaz.
• Tekilleştirme: dosyalar içerik tabanlı olarak değişken boyutlu parçalara bölünür; daha önce saklanmış parçalar tekrar gönderilmez. Bu yüzden ilk yedekten sonraki yedekler yalnız değişen veri kadar yer kaplar.
• Sıkıştırma: 0.14 sürümünden beri varsayılan depo biçimi (sürüm 2) sıkıştırmayı destekler; varsayılan ayar auto'dur.
• Anlık görüntüler (snapshot): her yedek bağımsız bir anlık görüntüdür. Belirli bir günün yedeğinden tek bir dosya ya da tüm dizin geri yüklenebilir. Linux, macOS ve FreeBSD'de depo bir klasör gibi bağlanıp (mount) içinde gezilebilir.

Parola uyarısı: restic'in kendi uyarısıyla, parolanın kaybolması verinin geri dönüşsüz kaybedilmesi demektir. Depo parolasını bir parola kasasında saklayın (ör. Vaultwarden) ve en az bir yetkili kişinin daha erişebildiğinden emin olun.

Yedek nereye alınır?

Resmi belgelerde desteklenen depolama türleri: yerel disk, SFTP, restic'in kendi REST sunucusu (rest-server), Amazon S3 ve S3 uyumlu depolar (MinIO, Wasabi vb.), Backblaze B2, Microsoft Azure Blob, Google Cloud Storage, OpenStack Swift ve rclone üzerinden onlarca başka servis. Belgeler, Linux'ta deponun CIFS (SMB) paylaşımında tutulmasını uyumluluk sorunları nedeniyle önermez.

KVKK açısından yedeğin nerede tutulduğu ayrıca önemlidir: yurt dışındaki bir bulut depolama kişisel veri aktarımı sayılabilir. Bu bilgi genel niteliktedir; kendi durumunuz için hukuk danışmanınızın görüşünü alın. Yedeği Türkiye'deki ikinci bir lokasyonda tutmak bu soruyu sadeleştirir.

Fidye yazılımına karşı: yalnız ekleme (append-only)

restic'in tehdit modeli açıktır: belgelere göre restic, depolama alanına yazma erişimi olan bir saldırganın dosyaları silmesine karşı koruma sağlamak için tasarlanmamıştır. Yedeklenen sunucu ele geçirilirse ve aynı kimlik bilgileriyle yedekler silinebiliyorsa, saldırgan yedekleri de yok edebilir. Bu yüzden yedeklerin silinemez olduğu ayrı bir katman gerekir:

• rest-server ile --append-only: resmi açıklamaya göre bu mod yeni yedek oluşturmaya izin verir ama mevcut yedeklerin silinmesini ve değiştirilmesini engeller. Böylece yedeklenen sunucuya erişim kazanan bir saldırgan, yedek sunucusundaki yedekleri silemez.
• Bakım ayrı ve güvenli bir makineden: belgelere göre yalnız ekleme düzeninde eski yedekleri temizleme (forget, prune) gibi tam erişim isteyen işler, ayrı ve iyi korunan bir istemciden yapılmalıdır. Belgeler ayrıca bu düzende forget komutunun --keep-within seçeneğiyle kullanılmasını önerir; böylece saldırganın eklediği sahte yedekler, gerçek yedeklerin silinmesine yol açmaz.
• S3 Object Lock: 0.13 sürümünün değişiklik notlarına göre restic, Object Lock açık S3 kovalarıyla çalışabilir. Saklama süresi kuralları restic tarafından değil, depolama tarafında tanımlanır.

Düzenli bakım: forget, prune ve check

• Saklama politikası: forget komutu hangi anlık görüntülerin tutulacağını belirler. Örneğin --keep-daily 7 --keep-weekly 5 --keep-monthly 12 son 7 günü, 5 haftayı ve 12 ayı saklar. Kullanılmayan veriyi asıl silen işlem prune'dur; ikisi forget --prune ile birlikte çalıştırılabilir.
• Kilitleme: belgelere göre veri silen bir işlem depoyu özel kilitle tutar; prune sırasında yedekler tamamlanamaz. Temizliği yedek saatlerinin dışına planlayın.
• Bütünlük denetimi: belgeler check komutunun düzenli çalıştırılmasını ve prune sonrasında da kullanılmasını önerir. --read-data-subset ile verinin bir bölümü her seferinde gerçekten okunarak denetlenebilir (ör. her hafta beşte biri).
• Geri yükleme denemesi: check deponun sağlam olduğunu gösterir, ama asıl kanıt geri yüklemedir. Belirli aralıklarla bir test sunucusuna gerçek geri yükleme yapın.

Veritabanı ve zamanlama

Çalışan bir veritabanının dosyalarını kopyalamak tutarsız bir yedek üretebilir. restic, 0.17 sürümünden beri --stdin-from-command seçeneğiyle bir döküm komutunun (ör. mysqldump) çıktısını doğrudan yedekleyebilir; bu yöntemde komutun hatayla bitmesi de fark edilir. Belgeler, çıktıyı boru (pipe) ile restic'e aktarmanın komut hatalarını gizleyip bozuk yedeğe yol açabileceği için önerilmediğini belirtir.

restic arka planda çalışan bir hizmet değil, çalıştırıldığında iş yapan bir araçtır; belgelere göre kendi zamanlayıcısı yoktur. Linux'ta cron ya da systemd zamanlayıcıları, Windows'ta Görev Zamanlayıcı kullanılır. Belgeler, yeni yedeği başlatmadan önce önceki çalışmanın bitip bitmediğinin kontrol edilmesini de ister. Windows'ta --use-fs-snapshot seçeneği, başka bir programın kilitlediği dosyaları VSS ile yedekleyebilir. Yedek işinin başarıyla bitip bitmediğini izlemek için Uptime Kuma'nın push izlemesi gibi bir sinyal kullanmak, sessizce duran yedekleri yakalamanın kolay yoludur.

restic kimler için uygun değil?

• Komut satırı kullanmayan ekipler: restic bir komut satırı aracıdır. Masaüstü arayüzü isteyen kullanıcılar için grafik arayüzlü araçlar daha uygundur.
• "Kur ve unut" bekleyenler: zamanlama, saklama politikası, check ve geri yükleme denemesi sizin kurmanız ve izlemeniz gereken işlerdir.
• Tek kopyayla yetinmek isteyenler: restic yedeği taşır, ama yedeğin silinemez ikinci kopyasını ve farklı lokasyonunu depolama düzeni sağlar.

e-veri.com ile restic

Sunucularınız ve şirket içi sistemleriniz için restic tabanlı yedekleme düzeni kuruyoruz:

• Türkiye'deki ikinci bir lokasyonda --append-only rest-server ya da S3 uyumlu depo
• Veritabanları için döküm komutuyla yedek
• Saklama politikası ve ayrı bir makineden yürütülen forget/prune
• Düzenli check ve dönemsel geri yükleme denemesi
• Yedek işlerinin izlenmesi

Kapsamı birlikte belirlemek için kurumsal hizmetler sayfamızdan bize yazın.

Sık sorulan sorular

restic yedekleri şifreli mi?

Evet. Resmi belgelere göre depoya yazılan tüm veri AES-256 (sayaç modu) ile şifrelenir ve Poly1305-AES ile doğrulanır. Depo parolası kaybolursa veri geri getirilemez.

restic hangi depolama türlerine yedek alabilir?

Yerel disk, SFTP, rest-server, Amazon S3 ve S3 uyumlu depolar, Backblaze B2, Azure Blob, Google Cloud Storage, OpenStack Swift ve rclone üzerinden başka servisler. Linux'ta deponun CIFS (SMB) paylaşımında tutulması önerilmez.

restic fidye yazılımına karşı korur mu?

Tek başına korumaz: belgelere göre restic, depolamaya yazma erişimi olan bir saldırganın dosyaları silmesini engellemek için tasarlanmamıştır. Koruma için rest-server'ın --append-only modu ya da Object Lock'lu S3 gibi silinemez bir depolama katmanı kullanılmalı, eski yedeklerin temizliği ayrı ve güvenli bir makineden yapılmalıdır.

restic yedekleri otomatik alır mı?

Hayır, restic'in kendi zamanlayıcısı yoktur. Linux'ta cron veya systemd zamanlayıcıları, Windows'ta Görev Zamanlayıcı ile düzenli çalıştırılır.

restic ile veritabanı yedeği nasıl alınır?

0.17 sürümünden beri --stdin-from-command seçeneğiyle mysqldump gibi bir döküm komutunun çıktısı doğrudan yedeklenebilir; komut hatayla biterse restic bunu fark eder. Çıktıyı boru ile aktarmak hataları gizleyebileceği için önerilmez.

Eski yedekler nasıl temizlenir?

forget komutu hangi anlık görüntülerin tutulacağını (ör. 7 günlük, 5 haftalık, 12 aylık) belirler; prune kullanılmayan veriyi siler. Belgeler, temizlikten sonra check komutuyla deponun denetlenmesini önerir.