Object Storage’a Otomatik Yedek Alma: rclone, restic ve Cron ile cPanel/VPS Yedekleri

Neden Object Storage’a Otomatik Yedek Almalısınız?

cPanel hesabınızda ya da kendi yönettiğiniz VPS sunucunuzda çalışan web siteleri büyüdükçe, yedekleme stratejisi masa başında konuşulup unutulacak bir konu olmaktan çıkıyor. Özellikle veritabanı yoğun WordPress, WooCommerce, Laravel tabanlı uygulamalar ve kritik müşteri verisi tutan SaaS projelerinde, tek bir yerel yedeğe güvenmek hem operasyonel hem de hukuki açıdan ciddi risk. Disk arızası, yanlışlıkla silme, hack vakası veya fidye yazılımı senaryolarında, aynı fiziksel sunucuda duran yedeğin çoğu zaman işe yaramadığını sahada defalarca gördük.

Tam da bu noktada, S3 uyumlu Object Storage üzerine otomatik alınan, sürümlenen ve şifrelenen yedekler oyunu tamamen değiştiriyor. Yedekleriniz; üretim sunucusundan fiziksel ve mantıksal olarak ayrılmış, coğrafi olarak farklı bir bölgede tutulabiliyor, saklama süresi ve maliyeti üzerinde çok daha esnek kontrol sağlıyor. Daha önce detaylı anlattığımız 3-2-1 yedekleme stratejisinin en pratik ayağı da tam olarak bu: üretim sunucusundan bağımsız bir kopya.

Bu yazıda, DCHost altyapısında ya da kendi VPS/cPanel sunucunuzda çalışan projeleriniz için; rclone, restic ve cron kullanarak S3 uyumlu Object Storage’a otomatik yedek alma mimarisini adım adım kuracağız. Amaç; elle komut çalıştırmadan, her gece (veya belirlediğiniz periyotta) çalışan, hem tam hem de artımlı yedekleri üreten, S3 tarafında saklama politikasını yöneten ve gerektiğinde hızlı geri dönüş sağlayan bir sistemi kalıcı hale getirmek.

Temeli Netleştirelim: cPanel mi, Düz VPS mi?

Önce hangi senaryoda olduğunuzu netleştirmek, doğru yedek setini belirlemek açısından kritik. DCHost tarafında en sık gördüğümüz iki ana durum var: paylaşımlı ya da reseller bir cPanel hesabı; veya tamamen size ait bir VPS/dedicated sunucu.

cPanel Senaryosu: Kullanıcı Hesabı Yedekleri

cPanel tarafında tipik olarak yedeklemek istediğimiz parçalar:

• Home dizini (public_html ve benzeri tüm site dosyaları)
• MySQL/MariaDB veritabanları
• E-posta kutuları ve ayarları
• cPanel hesabı yapılandırmaları (addon domainler, cron görevleri vb.)

cPanel kendi içinde tam hesap yedeği (.tar.gz) üretebiliyor. Daha önce cPanel’de tüm siteyi yedekleme ve geri yüklemeyi detaylı anlatmıştık. Bu makalede ise o üretilen arşivleri otomatik şekilde Object Storage’a taşıyacağız ve dilerseniz bunun yanına restic ile artımlı, dosya bazlı ekstra bir koruma katmanı ekleyeceğiz.

VPS/Dedicated Senaryosu: Uygulama + Veritabanı Yedekleri

Kontrol paneli olmayan bir VPS ya da dedicated sunucuda iş biraz daha esnek ama sorumluluk size ait. Burada tipik yedek bileşenleri:

• Uygulama dizinleri (örnek: /var/www, /srv/app, /opt/projects vb.)
• Veritabanı yedekleri (mysqldump, mariabackup, pg_dump, pgBackRest vb.)
• Önemli yapılandırma dosyaları (/etc altındaki belirli servis konfigürasyonları)
• Opsiyonel: loglar (genelde ayrı, daha kısa saklama politikası ile)

VPS senaryosunda sistem kaynak kullanımı daha kritik. Disk IO’yu kilitlemeden, CPU’yu tüketmeden ve ağ trafiğini boğmadan yedek almak için zamanlama, sıkıştırma ve bant genişliği limitleme katmanlarını iyi ayarlamak gerekiyor. Bu noktada VPS kaynak kullanımı izleme rehberimizde anlattığımız araçlarla yedekleme süreçlerini gözlemlemek büyük avantaj sağlar.

Object Storage ve S3 Uyumlu Depolamayı Kısaca Hatırlayalım

Object Storage, yedekleme tarafında neredeyse endüstri standardı haline geldi. Dosya sistemi ya da block storage yerine; her yedeği anahtar-değer mantığı ile nesne olarak saklıyor, altına meta veri ekleyebiliyor ve kolayca sürümleme yapabiliyorsunuz. Yedekleriniz bir bucket içinde tutuluyor ve HTTP tabanlı bir API ile erişiliyor.

Object Storage’ın yedekler için avantajları:

• Esnek ölçekleme: TB’larca veriyi tek hacim gibi yönetebilir, disk boyutu düşünmek zorunda kalmazsınız.
• Dayanıklılık: Nesneler genellikle birden fazla disk ve node üzerinde dağıtık şekilde saklanır.
• Versiyonlama: Aynı dosyanın farklı sürümlerini otomatik olarak tutabilir, yanlışlıkla silmeleri geri alabilirsiniz.
• Lifecycle politikaları: Eski yedekleri otomatik silme veya daha ucuz depolamaya aktarma senaryoları kurabilirsiniz.

Object, block ve file storage farklarını, hangi iş yükü için hangisinin mantıklı olduğunu ayrı bir yazıda detaylandırdık; arka planı tazelemek isterseniz Object Storage vs Block Storage vs File Storage rehberimize göz atabilirsiniz.

Oyuncular: rclone, restic ve Cron Ne İşe Yarıyor?

rclone: rsync’in Object Storage Dünyasındaki Kuzeni

rclone, dosya ve dizinleri yerel diskten S3 uyumlu Object Storage, FTP, SFTP ve daha pek çok uzak depolama tipine senkronize etmeyi sağlayan güçlü bir komut satırı aracı. Özellikle şu işlerde kullanacağız:

• cPanel’in ürettiği .tar.gz tam yedek arşivlerini S3 bucket’ına göndermek
• Yerel bir dizini Object Storage ile tek ya da çift yönlü senkronize etmek
• Opsiyonel olarak client-side şifreleme (rclone crypt) ile ek güvenlik katmanı kurmak

rclone’u daha derinlemesine kullanmak, S3 tarafında şifreleme ve lifecycle politikalarını birleştirmek isterseniz, bu makalenin devamı olarak kurgulayabileceğiniz rclone ile S3 yedek senkronizasyonu rehberimizi de incelemenizi öneririz.

restic: Artımlı, Şifreli ve Sürümlemeli Yedekler

restic, özellikle uzak depolama üzerinde artımlı ve deduplikasyonlu yedekler almak için tasarlanmış, modern bir yedekleme aracı. Öne çıkan özellikleri:

• Şifreli: Varsayılan olarak tüm veriyi istemci tarafında şifreler.
• Artımlı: Aynı dosyaların tekrar tekrar gönderilmesi yerine, sadece değişen blokları depolar.
• Sürümleme: Snapshot mantığı ile her yedek çalıştırmada yeni bir anlık görüntü oluşturur.
• Doğrudan S3 uyumu: Ek araca gerek kalmadan S3 uyumlu depolama ile konuşabilir.

restic ve alternatifleri olan Borg gibi araçları, saklama politikaları ve performans açısından karşılaştırdığımız restic ve Borg ile S3 uyumlu uzak yedekleme rehberimiz bu yazının teorik arka planı sayılabilir.

Cron: Otomatikleştiren Yapıştırıcı Katman

rclone ve restic çok güçlü araçlar, ancak manuel çalıştırıldıklarında bir süre sonra unutulmaya mahkumlar. İşte burada devreye cron giriyor. Cron ile:

• Her gece 03:00’te cPanel tam yedeği alıp rclone ile Object Storage’a yükleyebilirsiniz.
• Her 6 saatte bir restic ile web root ve veritabanı snapshotu oluşturabilirsiniz.
• Haftalık olarak restic forget/prune çalıştırıp eski snapshot’ları temizleyebilirsiniz.

Cron yerine systemd timer kullanmak daha esnek olabilir; hangisinin ne zaman mantıklı olduğunu merak ediyorsanız, cron mu systemd timer mı yazımız karar vermenize yardımcı olacaktır.

Mimari Tasarım: rclone mı, restic mi, Yoksa İkisi Birden mi?

Sahada en çok kullandığımız üç model var. Hangisini seçeceğiniz, veri büyüklüğü, geri dönüş süresi ve saklama maliyetine göre değişiyor.

Model 1: Sadece rclone ile Tam Arşiv Taşıma

Bu modelde cPanel ya da panelinizin ürettiği tam yedek arşivini (/backup gibi bir dizinde duran .tar.gz dosyaları) rclone ile Object Storage’a taşırsınız. Artımlı yedek yoktur; fakat:

• Yapı basittir, hata ayıklaması kolaydır.
• Yedek geri yükleme cPanel arayüzü ile pratik şekilde yapılabilir.

Model 2: Sadece restic ile Artımlı Yedek

Bu modelde cPanel’in kendi tam arşiv mekanizmasına yaslanmak yerine; web root, veritabanı dump’ları ve kritik config dosyalarını doğrudan restic ile S3’e yedeklersiniz. Avantajları:

• Artımlı ve deduplikasyonlu yapı sayesinde büyük projelerde ciddi alan tasarrufu sağlar.
• Tek dosya yerine snapshot tabanlı anlaşılır bir yapı sunar.
• Şifreleme varsayılan olduğu için KVKK/GDPR açısından daha güçlü bir hikaye anlatabilirsiniz.

Model 3: Hibrit Yaklaşım (rclone + restic)

Özellikle kurumsal projelerde en sevdiğimiz model bu:

• Gecelik cPanel tam hesap yedekleri rclone ile Object Storage’a gönderilir (tam geri yükleme kolaylığı).
• Daha sık (örneğin 4 saatte bir) restic ile web root + veritabanı snapshot’ları alınır (küçük RPO, hızlı geri dönüş).

Bu yazıda örnekleri hibrit yaklaşım üzerinden vereceğim; ama ihtiyacınıza göre sadece rclone veya sadece restic tarafını da kullanabilirsiniz.

Adım 1: Yedek Dizinlerini ve Kullanıcı Hesabını Hazırlama

İlk iş, yedeklerin yerelde nereye ineceğini ve hangi kullanıcıyla çalışacağını belirlemek.

• cPanel sunucusuysa: Genellikle root kullanıcısı altında /backup veya /home/backup dizini mantıklı.
• Tek VPS için: /opt/backups veya /srv/backups gibi özel bir dizin açabilirsiniz.

mkdir -p /opt/backups/{cpanel,restic}
chmod 700 /opt/backups

root ile çalışmak yerine sadece yedekleme için ayrı, sınırlı izinlere sahip bir sistem kullanıcısı oluşturmak, güvenlik açısından daha sağlıklıdır. Yine de cPanel tam yedekleri root yetkisi gerektirdiğinden, çoğu yapıda en azından bazı cron görevlerinde root devreye girecektir.

Adım 2: rclone Kurulumu ve S3 Uzak Depolama Tanımı

rclone Kurulumu

Çoğu modern Linux dağıtımında rclone’ı hızlıca kurabilirsiniz:

curl -O https://downloads.rclone.org/rclone-current-linux-amd64.zip
unzip rclone-current-linux-amd64.zip
cd rclone-*-linux-amd64
sudo cp rclone /usr/local/bin/
sudo chmod 755 /usr/local/bin/rclone

Versiyon yönetimini paket yöneticisi ile yapmak isterseniz, dağıtımınızın deposunda rclone paketi varsa onu da kullanabilirsiniz; fakat genellikle resmi binary daha güncel olur.

S3 Uyumlu Uzak Depolama Tanımı

Şimdi rclone’a DCHost Object Storage ya da kullandığınız S3 uyumlu servisin erişim bilgilerini tanıtalım:

rclone config

Sonra adım adım:

1. New remote seçin, ismine s3backup gibi anlamlı bir şey verin.
2. Storage türü olarak s3 seçin.
3. Provider kısmında generic veya kullandığınız servise uygun seçeneği işaretleyin.
4. Access key ve secret key bilgilerinizi girin.
5. Endpoint olarak DCHost Object Storage endpoint’inizi yazın (örnek: https://obj1.dchost.example).
6. Region, bucket adları ve diğer ayarları yönergelerine göre doldurun.

İlk bağlantıyı test etmek için:

rclone lsd s3backup:

komutunun bucket’larınızı listeliyor olması gerekir.

Adım 3: restic ile S3 Üzerinde Şifreli Depo (Repository) Oluşturma

restic Kurulumu

curl -L https://github.com/restic/restic/releases/download/v0.16.0/restic_0.16.0_linux_amd64 -o /usr/local/bin/restic
chmod 755 /usr/local/bin/restic

Versiyon numarasını güncel sürüme göre düzenlemeyi unutmayın.

restic Ortam Değişkenleri

restic’i her çağırdığınızda repoyu ve parolayı yazmak yerine, bunları bir environment dosyasına koymak çok daha pratik.

cat > /root/restic-env.sh << 'EOF'
export RESTIC_REPOSITORY='s3:https://obj1.dchost.example/bucket-adi/restic'
export RESTIC_PASSWORD='buraya-uzun-ve-guclu-bir-sifre-yazin'
export AWS_ACCESS_KEY_ID='access-key'
export AWS_SECRET_ACCESS_KEY='secret-key'
EOF

chmod 600 /root/restic-env.sh

Buradaki AWS_ACCESS_KEY_ID isimlendirmesi sizi yanıltmasın; restic S3 uyumlu tüm servislerle bu değişken isimlerini kullanıyor, illaki belirli bir sağlayıcıya işaret etmiyor.

restic Deposu Oluşturma

source /root/restic-env.sh
restic init

Bu komut, Object Storage üzerindeki bucket altında restic’in kullanacağı repository yapısını oluşturur. Artık her yedek aldığınızda bu repoya yeni snapshot’lar eklenecek.

Adım 4: cPanel Tam Yedeklerini rclone ile Object Storage’a Taşımak

cPanel’de Tam Yedek Oluşturma

cPanel tarafında iki yol var:

• WHM üzerinde sunucu yöneticisiyseniz, Backup Configuration ile otomatik günlük/haftalık tam yedek aldırabilirsiniz.
• Tek cPanel hesabı kullanıyorsanız, kullanıcı panelindeki Backup veya Backup Wizard ile tam yedek üretebilirsiniz.

WHM üzerinden otomatik tam yedek alacak şekilde yapılandırdığınızı ve çıktının /backup altında oluştuğunu varsayalım. Tipik dosya ismi şu şekilde olur:

/backup/2024-12-26/accounts/kullanici.tar.gz

rclone ile cPanel Yedek Dizinini Senkronize Etmek

Şimdi bu dizini S3 tarafındaki bir klasöre senkronize edelim. Önce manuel test:

rclone sync 
  /backup/ 
  s3backup:cpanel-full-backups/ 
  --transfers=4 
  --checkers=8 
  --bwlimit=5M 
  --delete-after

Burada:

• –bwlimit=5M ile ağ trafiğini sınırlayıp diğer servisleri boğmuyoruz.
• –delete-after ile yerelde silinen eski yedeklerin Object Storage tarafında da temizlenmesini sağlıyoruz (bunu kurum politikanıza göre dikkatle kullanın).

cPanel Yedek Taşıma İçin Cron Görevi

WHM’de yedeklerin örneğin gece 02:00’de üretildiğini biliyorsanız, rclone senkronizasyonunu 03:00’e koyabilirsiniz. root crontab:

crontab -e

İçine şu satırı ekleyin:

0 3 * * * /usr/local/bin/rclone sync /backup/ s3backup:cpanel-full-backups/ 
  --transfers=4 --checkers=8 --bwlimit=5M --delete-after 
  >> /var/log/rclone-cpanel-backup.log 2>&1

Böylece her gece 03:00’te senkronizasyon tetiklenecek, logları da /var/log/rclone-cpanel-backup.log dosyasından takip edebileceksiniz.

Adım 5: restic ile Web Root + Veritabanı Artımlı Yedekleri

Şimdi işin daha esnek kısmına, restic ile artımlı yedeklemeye geçelim. Burada iki adım var: önce veritabanı dump’larını almak, sonra web root ve dump’ları birlikte restic’e yazmak.

Veritabanı Dump Alma Script’i

MySQL/MariaDB için basit bir örnek:

cat > /opt/backups/db-dump.sh << 'EOF'
#!/bin/bash
set -e
BACKUP_DIR='/opt/backups/db-dumps'
mkdir -p "${BACKUP_DIR}"

# Kullanıcı ve parola için my.cnf kullanmanız daha güvenli olacaktır

DATE=$(date +%F-%H%M)
mysqldump --all-databases --single-transaction --quick 
  | gzip > "${BACKUP_DIR}/alldb-${DATE}.sql.gz"

# 7 günden eski dump dosyalarını temizle
find "${BACKUP_DIR}" -type f -mtime +7 -delete
EOF

chmod 700 /opt/backups/db-dump.sh

restic ile Dosya + Veritabanı Snapshot’ı

Şimdi web root dizini ve veritabanı dump’larını birlikte restic’e yedekleyen script’i yazalım:

cat > /opt/backups/restic-backup.sh << 'EOF'
#!/bin/bash
set -e

source /root/restic-env.sh

WEB_ROOT='/var/www'
DB_DUMPS='/opt/backups/db-dumps'

# Önce veritabanı dump'ını al
/opt/backups/db-dump.sh

# Ardından restic backup çalıştır
restic backup "${WEB_ROOT}" "${DB_DUMPS}" 
  --tag daily 
  --hostname "$(hostname)"

# Saklama politikası: son 7 günlük, 4 haftalık ve 6 aylık snapshot'ları tut
restic forget --prune 
  --keep-daily 7 
  --keep-weekly 4 
  --keep-monthly 6
EOF

chmod 700 /opt/backups/restic-backup.sh

Buradaki saklama politikasını kendi RPO/RTO hedeflerinize göre düzenleyebilirsiniz. Daha sık snapshot almak istiyorsanız keep-daily/keep-weekly değerlerini artırmak mantıklı olabilir. Bu konuyu felaket kurtarma planınızla birlikte düşünmek için felaket kurtarma planı nasıl yazılır rehberimize de göz atmanızı öneririm.

restic Yedekleri için Cron

Bu artımlı yedekleri günde bir yerine, örneğin 4 saatte bir almak çoğu proje için sağlıklı bir denge sunuyor. root crontab’a:

0 */4 * * * /opt/backups/restic-backup.sh 
  >> /var/log/restic-backup.log 2>&1

satırını eklediğinizde, restic her 4 saatte bir yeni snapshot alacak. Disk ve ağ yükünü izleyerek bu periyodu ihtiyaca göre yukarı ya da aşağı çekebilirsiniz.

VPS Özelinde İnce Ayarlar: Kaynak Kullanımı, Güvenlik ve Loglar

Kaynak Kullanımını Sakin Tutmak

Özellikle CPU ve disk IO açısından hassas VPS’lerde, yedekleme sırasında üretim trafiğini rahatsız etmemek için şu adımları öneriyoruz:

• Yedekleme script’lerini düşük yoğunluklu saatlere (örneğin gece) koyun.
• rclone ve restic komutlarını nice ve ionice ile düşük öncelikli çalıştırın:

nice -n 10 ionice -c2 -n7 restic backup ...

Diskin dolmasını önlemek için log dosyalarınızı da kontrol altında tutmanız şart. Bunun için VPS disk kullanımı ve logrotate ayarlarıyla no space left on device hatasını önlemek rehberindeki önerileri bu yedekleme mimarisiyle birleştirmenizi tavsiye ederiz.

Güvenlik: Erişim Anahtarları ve Şifreleme

Yedekler en az üretim verisi kadar hassas, hatta çoğu zaman daha da kritik; çünkü hepsi tek yerde toplanmış durumda. Güvenlik tarafında temel prensipler:

• S3 erişim anahtarı için sadece gerekli yetkilere sahip (sınırlı bucket erişimli) ayrı bir kullanıcı tanımlayın.
• Anahtarları script’lere gömmek yerine environment dosyalarında ve mümkünse sadece root okunabilir şekilde saklayın.
• restic zaten client-side şifreleme sağlıyor; buna ek olarak Object Storage tarafında server-side şifrelemeyi de aktif etmeyi düşünün.
• rclone config dosyasını (genelde /root/.config/rclone/rclone.conf) 600 izinleriyle sınırlayın.

KVKK ve GDPR tarafında veri yerelleştirme, saklama süresi ve silme politikalarını kurarken, bu yedekleme mimarisini daha geniş bir çerçeveye oturtmak için KVKK ve GDPR uyumlu hosting stratejisi yazımızı da mutlaka okuyun.

Loglama ve Alarm: Sessizce Bozulan Yedekleri Yakalamak

rclone ve restic komutlarının çıktısını log dosyalarına yönlendirmek güzel bir başlangıç; ama yeterli değil. En azından şu adımları öneriyoruz:

• Hata durumunda e-posta atan bir wrapper script kullanın (exit code kontrolü).
• Log dosyalarının son satırını gün içinde otomatik kontrol eden basit bir cron daha ekleyin.
• Daha ileri seviye için Prometheus/Grafana veya benzeri izleme sistemlerine başarı/başarısızlık metrikleri gönderin.

Böylece bir gün rclone ya da restic sessizce hata vermeye başlarsa, aylar sonra fark etmek yerine aynı gün içinde harekete geçebilirsiniz.

Geri Dönüş Testi: Yedek Almak Değil, Dönmek Esastır

Teoride her şey güzel; ama işin pratiğinde en kritik adım, periyodik geri dönüş testi. Yedeklerinizin gerçekten işe yarayıp yaramadığını, test etmeden bilemezsiniz. Önerdiğimiz yaklaşım:

• Ayda en az bir kez, farklı bir test VPS üzerinde deneme geri yükleme yapın.
• cPanel tam yedeğini Object Storage’tan indirip WHM veya cPanel arayüzüyle geri yükleyin.
• restic snapshot’larından belirli bir tarihi seçip sadece o siteye ait dosyaları ve veritabanını çıkarın.
• Uygulama ayağa kalkıyor mu, hata logları temiz mi, admin paneline giriş yapılabiliyor mu tek tek kontrol edin.

Bu süreci şirket içinde bir runbook ve kontrol listesi ile standardize etmek istiyorsanız, felaket kurtarma planı rehberimizde örnek senaryoları ve dokümantasyon önerilerini detaylı anlattık.

DCHost Tarafında Bu Mimarinin Nereye Oturduğu

DCHost olarak verdiğimiz domain, hosting, VPS, dedicated ve colocation hizmetlerinde yedekleme mimarisini her zaman ayrı bir katman olarak ele alıyoruz. Bu yazıda anlattığımız rclone + restic + cron kombinasyonu:

• Küçük ve orta ölçekli projelerde, tek VPS üzerinde oldukça ekonomik ve esnek bir çözüm sunuyor.
• Ajansların yönettiği çoklu cPanel hesaplarında, merkezi bir Object Storage üzerinde tüm müşteri yedeklerini konsolide etmeyi mümkün kılıyor.
• Dedicated ve colocation müşterilerinde, kendi veri merkeziniz ile DCHost Object Storage arasında hibrit bir felaket kurtarma senaryosu kurmanın temelini oluşturuyor.

Mevcut altyapınızı analiz edip, RPO/RTO hedeflerinizle uyumlu, otomatik testleri tanımlanmış bir yedekleme mimarisi kurmak istiyorsanız, DCHost ekibi olarak bu yazıdaki yaklaşımı sizin projelerinize özel bir plan haline getirebiliriz. İster tek bir cPanel hesabı, ister onlarca VPS veya dedicated sunucu olsun; önemli olan, yedekleme zincirinin her halkasını tasarlayıp düzenli test eden, sürdürülebilir bir yapı kurmak.

Özetle: rclone ile ham arşivleri güvenli bir Object Storage’a taşıyın, restic ile artımlı ve şifreli snapshot’lar alın, cron ile hepsini otomatik hale getirin ve düzenli geri dönüş testleri ile bu zincirin gerçekten çalıştığını doğrulayın. Gerisi, altyapınızı büyütürken size eşlik edecek sağlıklı bir yedekleme alışkanlığına kalıyor.