Restic ile Şifreli Bulut Yedekleme

Bir sunucuyu yıllarca sorunsuz çalıştırabilirsiniz, ama gerçek sınav her zaman "veriyi kaybettiğiniz gün" gelir. Yanlışlıkla silinen bir veritabanı, bir ransomware saldırısı ya da fiziksel disk arızası; bu üçünden herhangi biri, yedeğiniz yoksa işinizi tek bir gecede bitirebilir. Klasik rsync veya tar tabanlı yedekler işi bir yere kadar götürür, fakat şifreleme, tekilleştirme (deduplication) ve bulut depolamayı tek araçta birleştirmek istediğinizde tablo değişir. İşte Restic tam bu boşluğu doldurmak için tasarlanmış, tek binary'den ibaret, hızlı ve modern bir yedekleme aracıdır.

Bu rehberde Restic'in neden ciddi bir sistem yöneticisinin çantasında olması gerektiğini, deposunu (repository) nasıl başlattığınızı, ilk yedeği nasıl aldığınızı, snapshot'ları nasıl yönettiğinizi, S3 ve Backblaze B2 gibi bulut backend'lerini nasıl bağladığınızı, saklama politikasını forget ve prune ile nasıl kurduğunuzu ve cron ile tüm süreci nasıl otomatikleştirdiğinizi uygulamalı komutlarla ele alacağız. Daha basit senaryolar için rsync ile yedekleme yazımız iyi bir başlangıç noktasıdır; Restic ise bir adım öteye, şifreli ve bulut merkezli yedeklemeye geçmek isteyenler içindir.

Restic Nedir ve Neden Tercih Edilir#

Restic, Go diliyle yazılmış açık kaynaklı bir yedekleme aracıdır. Tek bir çalıştırılabilir dosyadan ibaret olması onu son derece pratik kılar; harici bağımlılık, veritabanı ya da servis kurmadan çalışır. Yedeklediğiniz verinin tamamı, deponuza yazılmadan önce istemci tarafında AES-256 ile şifrelenir. Bu, deponun bulunduğu diske veya bulut kovasına erişen birinin bile parolanız olmadan içeriği okuyamayacağı anlamına gelir. Bu "sıfır güven" yaklaşımı, veriyi güvenmediğiniz üçüncü taraf depolamaya (herhangi bir S3 sağlayıcısı gibi) koyarken paha biçilmezdir.

Restic'i öne çıkaran ikinci büyük özellik tekilleştirmedir. Veriyi sabit boyutlu değil, içeriğe dayalı değişken boyutlu bloklara (chunk) böler ve her bloğu yalnızca bir kez saklar. Aynı dosya on farklı dizinde bulunsa da depoda tek bir kopyası tutulur; iki snapshot arasında yalnızca birkaç byte değişmişse yalnızca o değişen bloklar yazılır. Bunun pratikteki sonucu şudur: her gün "tam yedek" alırmış gibi komut çalıştırırsınız ama depoda yalnızca artan fark kadar yer kaplar. Buna bir de otomatik bütünlük doğrulama (check), anlık görüntü (snapshot) mantığı ve çok sayıda bulut backend desteği eklenince, Restic küçük bir VPS'ten büyük bir kurumsal filoya kadar ölçeklenen bir çözüm haline gelir. Yedeklemenin altyapı tarafını bize bırakmak isterseniz yedekleme hizmetlerimize göz atabilirsiniz.

Kurulum ve İlk Depo Başlatma#

Restic'i kurmak çoğu dağıtımda tek komuttur. Depo yöneticisinden gelen sürüm bazen eski olabildiği için, güncel özellikler istiyorsanız resmi binary'i indirmek de makul bir seçenektir.

# Debian / Ubuntu
apt update && apt install -y restic

# AlmaLinux / Rocky
dnf install -y epel-release && dnf install -y restic

# Kurulumu doğrula
restic version

Restic'te her şey bir "repository" (depo) etrafında döner. Depo, şifreli yedek bloklarınızın, snapshot metaverisinin ve anahtarların tutulduğu yerdir. Herhangi bir yedek almadan önce depoyu bir kez başlatmanız gerekir. Yerel bir diske örnek başlatma şöyledir:

# Depo parolasını ortam değişkeninden ver (interaktif sormasın)
export RESTIC_PASSWORD='cok-guclu-bir-parola'
export RESTIC_REPOSITORY='/yedek/restic-repo'

restic init

Komut çalıştığında Restic depoyu oluşturur ve şifreleme anahtarını parolanızdan türetir. Bu noktada kritik bir uyarı: bu parolayı kaybederseniz deponuzdaki hiçbir veriye asla erişemezsiniz. Restic'te parola sıfırlama, kurtarma sorusu ya da arka kapı yoktur; bu, şifrelemenin gerçekten güçlü olmasının bedelidir. Parolayı bir parola yöneticisinde saklamak ve düz metin olarak RESTIC_PASSWORD yerine --password-file ile korunan bir dosyadan okumak daha sağlıklıdır:

# Parolayı yalnızca root'un okuyabileceği bir dosyaya koy
echo 'cok-guclu-bir-parola' > /root/.restic-pass
chmod 600 /root/.restic-pass

restic -r /yedek/restic-repo --password-file /root/.restic-pass init

İlk Yedeği Almak ve Snapshot Yönetimi#

Depo hazır olduğunda yedek almak restic backup ile yapılır. Yedeklemek istediğiniz dizinleri argüman olarak verirsiniz; Restic bunları tarar, blokları şifreleyip depoya yazar ve sonuçta bir snapshot oluşturur. Snapshot, o andaki dosya ağacının değişmez bir fotoğrafıdır.

# Web dosyalarını ve yapılandırmayı yedekle
restic -r /yedek/restic-repo --password-file /root/.restic-pass \
  backup /var/www /etc/nginx

# Belirli desenleri hariç tut
restic backup /var/www \
  --exclude='*.log' \
  --exclude='/var/www/*/cache' \
  --exclude-caches

--exclude-caches bayrağı, içinde CACHEDIR.TAG işaretçisi bulunan önbellek dizinlerini otomatik atlar; gereksiz veriyi depodan uzak tutmanın pratik bir yoludur. Yedekleri etiketlemek de günlük operasyonu kolaylaştırır; --tag gunluk ya da --tag manuel gibi etiketler daha sonra filtrelemeyi çok basitleştirir.

Aldığınız snapshot'ları listelemek ve içeriklerini incelemek için birkaç temel komut yeterlidir:

# Tüm snapshot'ları listele (kısa ID, tarih, host, etiket)
restic snapshots

# Belirli bir snapshot içindeki dosya ağacını gör
restic ls 3f8a1c2d

# İki snapshot arasındaki farkı gör
restic diff 3f8a1c2d 9b4e7f01

# Deponun bütünlüğünü doğrula
restic check

restic check komutunu düzenli çalıştırmayı alışkanlık edinin. Yedeğin var olması yetmez; geri yüklenebilir olması gerekir. Ayda bir restic check --read-data ile blokların gerçekten okunabildiğini doğrulamak, "yedeğim vardı ama bozukmuş" felaketinin önüne geçer.

S3, Backblaze B2 ve Diğer Bulut Backend'leri#

Restic'in en güçlü yanı, aynı komutları neredeyse hiç değiştirmeden farklı depolama arka uçlarında kullanabilmenizdir. Depo yolunu (RESTIC_REPOSITORY) değiştirmek çoğu zaman tek fark olur. Aşağıdaki tablo en çok kullanılan backend'lerin repo dizesini özetler:

S3 uyumlu bir depoya yedek almak için önce erişim anahtarlarını ortam değişkeni olarak tanımlar, sonra depoyu başlatırsınız:

export AWS_ACCESS_KEY_ID='ERISIM_ANAHTARI'
export AWS_SECRET_ACCESS_KEY='GIZLI_ANAHTAR'
export RESTIC_REPOSITORY='s3:https://s3.eu-central-1.amazonaws.com/sirket-yedek'
export RESTIC_PASSWORD_FILE='/root/.restic-pass'

restic init
restic backup /var/www /etc

Backblaze B2, S3'e göre genellikle daha ekonomik olduğu için Restic kullanıcıları arasında çok popülerdir. Kurulumu neredeyse aynıdır:

export B2_ACCOUNT_ID='hesap-id'
export B2_ACCOUNT_KEY='uygulama-anahtari'
export RESTIC_REPOSITORY='b2:sirket-yedek:sunucu1'
export RESTIC_PASSWORD_FILE='/root/.restic-pass'

restic init
restic backup /var/www

Bulut senaryosunda tekilleştirme ve şifreleme birlikte parlar: veri kovaya çıkmadan önce şifrelendiği için sağlayıcının veriyi okuma ihtimali yoktur; tekilleştirme sayesinde de her gün yedek almanıza rağmen depolama maliyeti kontrol altında kalır. Yedeklerinizi barındıracağınız güçlü bir alt yapı için VDS sunucularımızı veya bir yönetici desteği istiyorsanız sunucu yönetimi hizmetimizi değerlendirebilirsiniz.

Şifreleme, Parola ve Anahtar Yönetimi#

Restic'te şifreleme opsiyonel değildir; her depo baştan sona şifrelidir. İçeride birden çok "anahtar" olabilir ve her anahtar bir parolaya bağlıdır. Bu, tek bir depoya birden fazla erişim parolası tanımlamanıza olanak tanır; örneğin bir parola sizin, biri ise otomasyon sunucusunun olabilir. Böylece birini iptal ederken diğerini bozmazsınız.

# Depoya yeni bir anahtar (parola) ekle
restic key add

# Mevcut anahtarları listele
restic key list

# Belirli bir anahtarı kaldır
restic key remove <anahtar-id>

Otomasyon için parolayı düz metin ortam değişkeninde tutmak yerine, komut çıktısından okuyan RESTIC_PASSWORD_COMMAND daha güvenli bir yöntemdir. Böylece parola bir sır yöneticisinden (örneğin pass ya da bir vault aracı) anlık alınır ve process listelerinde görünmez:

export RESTIC_PASSWORD_COMMAND='pass show sunucu/restic'
restic snapshots

Bu noktada operasyonel bir gerçeği tekrar vurgulamak gerekir: şifreleme ne kadar güçlüyse, parola kaybının bedeli de o kadar ağırdır. Parolayı en az iki farklı güvenli yerde (bir parola yöneticisi ve fiziksel/çevrimdışı bir kopya) saklayın. Sunucu güvenliğinizin genel çerçevesini gözden geçirmek isterseniz SSH bağlantısı ve güvenliği yazımız, yedek anahtarlarınızı barındıran makineyi sıkılaştırmak için iyi bir kaynaktır.

forget ve prune ile Saklama Politikası#

Her gün yedek alırsanız zamanla yüzlerce snapshot birikir. Hepsini sonsuza dek tutmak hem gereksiz hem de bulut maliyetini artırır. Restic bu noktada iki adımlı bir mantık kullanır: forget hangi snapshot'ların mantıksal olarak tutulacağına karar verir, prune ise artık hiçbir snapshot'a ait olmayan blokları depodan fiziksel olarak siler.

forget komutunun gücü, esnek saklama politikalarındadır. Aşağıdaki komut son 7 günün her gününü, son 4 haftanın her haftasını ve son 6 ayın her ayını korur; geri kalanları unutur:

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

--prune bayrağını forget ile birlikte vermek, unutma ve fiziksel temizliği tek adımda yapar. Politikayı önce --dry-run ile denemek, hangi snapshot'ların gerçekten silineceğini görmenizi sağlar ve yanlış politika yüzünden değerli bir yedeği kaybetme riskini ortadan kaldırır:

# Önce ne olacağını gör (hiçbir şey silinmez)
restic forget --keep-daily 7 --keep-weekly 4 --dry-run

Tipik bir üretim politikası, kısa vadede sık, uzun vadede seyrek yedek tutmak üzerine kuruludur. Aşağıdaki tablo yaygın bir yaklaşımı özetler:

Cron ile Otomatik Yedekleme#

Manuel yedek unutulmaya mahkumdur; gerçek koruma otomasyondan gelir. Restic'i cron ile zamanlamak için önce tüm ortam değişkenlerini ve komutları içeren küçük bir betik yazmak en temiz yöntemdir. Böylece kimlik bilgileri cron satırında görünmez ve betiği elle de çalıştırabilirsiniz.

#!/usr/bin/env bash
# /usr/local/bin/restic-yedek.sh
set -euo pipefail

export RESTIC_REPOSITORY='b2:sirket-yedek:sunucu1'
export RESTIC_PASSWORD_FILE='/root/.restic-pass'
export B2_ACCOUNT_ID='hesap-id'
export B2_ACCOUNT_KEY='uygulama-anahtari'

# Yedek al
restic backup /var/www /etc /home \
  --exclude-caches \
  --tag gunluk

# Saklama politikasını uygula ve temizle
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# Ayda bir tam bütünlük kontrolü ekleyebilirsiniz (cron ayrı)

Betiği çalıştırılabilir yapıp cron'a ekleyin. Aşağıdaki örnek her gece 03.15'te yedek alır ve çıktı ile hataları bir log dosyasına yazar:

chmod +x /usr/local/bin/restic-yedek.sh

# crontab -e içine:
15 3 * * * /usr/local/bin/restic-yedek.sh >> /var/log/restic.log 2>&1

Otomasyonun altın kuralı: bildirim olmadan otomasyona güvenmeyin. Betiğin sonuna, başarısızlık durumunda size e-posta ya da webhook gönderen birkaç satır eklemek, "aylardır yedek almıyormuşum" sürprizini engeller. Cron mantığını derinlemesine görmek isterseniz Linux cron görevleri yazımız zamanlamanın tüm inceliklerini anlatır. Ayrıca panelimizdeki uptime ve durum izleme araçlarıyla yedek sunucunuzun ayakta olduğunu da takip edebilirsiniz.

Geri Yükleme Senaryoları#

Bir yedeğin tek amacı geri yüklenebilmesidir, bu yüzden restore komutunu bilmek ve düzenli test etmek şarttır. En basit haliyle, bir snapshot'ın tamamını bir hedef dizine geri yazarsınız.

# Snapshot'ı listele, doğru ID'yi bul
restic snapshots

# Tüm snapshot'ı bir hedefe geri yükle
restic restore 3f8a1c2d --target /kurtarma

# Sadece belirli bir alt dizini geri yükle
restic restore 3f8a1c2d --target /kurtarma --include /var/www/site1

# En son snapshot'ı geri yükle (kısa yol)
restic restore latest --target /kurtarma

Bazen tüm dizini geri yüklemek yerine tek bir dosyaya bakmak istersiniz. Restic bunun için deponuzu bir dizin gibi bağlayabilen mount özelliği sunar; snapshot'lar arasında sanki normal klasörlermiş gibi gezinip istediğiniz dosyayı kopyalarsınız:

mkdir /mnt/restic
restic mount /mnt/restic
# Başka bir terminalde:
ls /mnt/restic/snapshots/latest/var/www
cp /mnt/restic/snapshots/latest/var/www/config.php /geri/

Geri yüklemeyi asla "gerçek felaket günü" ilk kez denemeyin. Üç ayda bir, rastgele bir snapshot'ı boş bir dizine geri yükleyip verinin bütün ve tutarlı olduğunu doğrulayın. cPanel tabanlı barındırmada panel üzerinden yedek alıp geri yükleme akışını da bilmek işinize yarar; bunun için cPanel yedekleme rehberimize göz atabilirsiniz. Sunucu göçü gibi büyük operasyonlarda site taşıma ekibimizden de destek alabilirsiniz.

Restic mi Borg mu? Bulut Senaryosu#

Restic'in en yakın rakibi genellikle BorgBackup'tır ve ikisi de tekilleştirme ile şifreleme sunar. Ancak tasarım felsefeleri farklıdır ve doğru araç senaryonuza bağlıdır. Aşağıdaki karşılaştırma en kritik farkları özetler:

Kabaca özet şudur: yedeği doğrudan bir S3/B2 kovasına, kendi yönetiminiz altında olmayan bir depolamaya yazacaksanız Restic çok daha rahat bir seçimdir; çünkü backend desteği yerleşiktir ve şifreleme varsayılan olarak açıktır. Eğer yedeği tamamen sizin kontrolünüzdeki başka bir Linux sunucuya SSH üzerinden alıyorsanız ve maksimum sıkıştırma/ince ayar istiyorsanız Borg da güçlü bir alternatiftir. Çoğu web barındırma ve VPS kullanıcısı için, "kur, parolayı sakla, kovaya yaz" basitliği nedeniyle Restic pratikte daha az sürtünmeli bir deneyim sunar. İş yükünüz büyükse ölçeklenebilir sanal sunucu çözümlerimiz yedek istemcisini barındırmak için uygun bir zemin sağlar.

Sıkça Sorulan Sorular#

Restic depo parolamı unutursam ne olur?#

Depo parolasını tamamen kaybederseniz, o depodaki hiçbir veriye erişemezsiniz ve bunu geri getirmenin bir yolu yoktur. Restic'te parola sıfırlama, kurtarma anahtarı ya da arka kapı bulunmaz; bu, şifrelemenin gerçekten güçlü olmasının doğal sonucudur. Bu yüzden parolayı bir parola yöneticisinde ve ayrıca çevrimdışı bir kopyada saklamak, kritik önemdedir. Tek bir depoya birden çok anahtar (parola) tanımlayarak da kendinize yedek erişim yolu bırakabilirsiniz.

Restic gerçekten tam yedek mi yoksa artımlı yedek mi alıyor?#

Kullanıcı açısından her backup komutu tam yedek gibi davranır, çünkü sonuçta o anki verinin eksiksiz bir snapshot'ını elde edersiniz. Ancak Restic içeride tekilleştirme yaptığı için, yalnızca önceki yedeklerde bulunmayan yeni blokları depoya yazar. Yani depolama ve aktarım açısından davranış artımlı yedeğe benzer, ama her snapshot bağımsız olarak geri yüklenebilir. Bu, "hangi tam yedeğe hangi artımlı zinciri bağlamalıyım" karmaşasını tamamen ortadan kaldırır.

Yedeklerimi hangi bulut sağlayıcısında tutmalıyım?#

Restic; Amazon S3, Backblaze B2, MinIO, Azure, Google Cloud Storage ve daha birçok S3 uyumlu servisle çalışır. Maliyet önceliğiniz ise Backblaze B2 genellikle en ekonomik seçeneklerden biridir ve Restic ile kurulumu çok basittir. Veri egemenliği ve düşük gecikme önemliyse, verinize coğrafi olarak yakın bir bölge seçmek daha mantıklı olur. Şifreleme istemci tarafında yapıldığından, hangi sağlayıcıyı seçerseniz seçin sağlayıcının verinizi okuyamayacağından emin olabilirsiniz.

Restic yedekleri ne kadar sık almalıyım?#

İdeal sıklık, verinin ne kadar hızlı değiştiğine bağlıdır. Aktif bir e-ticaret sitesi ya da sık işlem gören bir veritabanı için gecelik yedek çoğu zaman minimum kabul edilir; kritik sistemlerde saatlik yedek bile mantıklı olabilir. Tekilleştirme sayesinde sık yedek almak depolama maliyetini ölçüsüz artırmaz, bu yüzden sıklığı yüksek tutmak genelde güvenlidir. Sıklığı, forget ile kurduğunuz saklama politikasıyla birlikte tasarlamak en sağlıklı yaklaşımdır.

prune komutu çalışırken yedek almak güvenli mi?#

Aynı depo üzerinde eşzamanlı prune ve backup çalıştırmaktan kaçınmalısınız, çünkü prune kullanılmayan blokları silerken deponun yapısını yeniden düzenler. Restic bir kilit mekanizması kullanır ve genellikle çakışan işlemleri engeller, ancak yine de bakım işlemlerini (prune, check) yedek pencerelerinin dışına zamanlamak en temiz yöntemdir. Pratikte gecelik yedeği bir saatte, haftalık prune'u ise farklı bir saatte planlamak bu riski tamamen ortadan kaldırır. Böylece hem yedekler kesintisiz akar hem de depo sağlıklı biçimde temizlenir.

Restic veritabanlarını doğrudan yedekleyebilir mi?#

Restic dosya tabanlı çalışır, bu yüzden bir veritabanının canlı dosyalarını doğrudan yedeklemek tutarsız (bozuk) bir kopyaya yol açabilir. Doğru yöntem, önce mysqldump veya pg_dump ile tutarlı bir dökümü diske almak, ardından o döküm dosyasını Restic ile yedeklemektir. Alternatif olarak veritabanı dökümünü bir boru hattıyla doğrudan Restic'in --stdin girdisine besleyip depolama alanından tasarruf edebilirsiniz. Bu sayede hem uygulama dosyalarınız hem de veritabanınız aynı tutarlı yedek stratejisinin parçası olur.

Kapanış#

Restic, "kurulumu basit ama gücü derin" araçların güzel bir örneğidir: tek bir binary ile şifreli, tekilleştirilmiş ve buluta hazır bir yedekleme altyapısı kurabilir, cron ile tamamen otomatikleştirebilir ve forget/prune ile maliyeti kontrol altında tutabilirsiniz. Unutmayın ki bir yedek stratejisi ancak düzenli test edilen geri yüklemelerle gerçek bir güvence sunar; bu yüzden restic check ve deneme restore işlemlerini takviminize alın.

Yedeklerinizi barındıracak güçlü ve yönetimi kolay bir zemine ihtiyacınız varsa Clou.TR olarak yanınızdayız. Yüksek performanslı VDS sunucularımızla, dilerseniz her şeyi biz üstlenelim diyen sunucu yönetimi hizmetimizle ya da düzenli yedek altyapısı için yedekleme çözümlerimizle verinizi güvence altına alabilirsiniz. Doğru araç ve doğru altyapı bir araya geldiğinde, "veriyi kaybettiğiniz gün" hiç gelmez; gelse bile sizin için sıradan bir geri yükleme işleminden ibaret kalır.