Object Storage Yedekleme: cPanel ve VPS Rehberi

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 ciddi bir operasyonel risk oluşturur; hukuki sonuçlar ise geçerli yükümlülüklere ve olayın koşullarına bağlıdır. Disk arızası, yanlışlıkla silme, hack vakası veya fidye yazılımı senaryolarında, aynı fiziksel sunucuda duran yedek de üretim verisiyle birlikte zarar görebilir.

S3 uyumlu Object Storage, üretim sunucusundan bağımsız bir kopya tutmak için kullanılabilir. Ayrı bölge, sürümleme ve saklama özellikleri hizmetin desteğine ve yapılandırmanıza bağlıdır. Düz rclone kopyası kendiliğinden istemci tarafında şifrelenmez; restic şifrelemesi ayrı akıştır. 3-2-1 yedekleme stratejisi, kopyaların ortak arızadan etkilenmemesini planlamaya yardımcı olur.

Bu rehberde cPanel ve VPS için Object Storage yedekleme akışını rclone, restic ve cron ile kuracağız: tamamlanan hesap arşivini kopyalama, tutarlılık koşulları belirlenmiş veritabanı dump’ı üretme, artımlı snapshot alma, saklama ve test ortamına geri yükleme. Komut örnekleri Linux üzerinde root Bash oturumu içindir; paylaşımlı hesapların yetki sınırları ayrıca açıklanır.

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. Bu rehber iki ana senaryoyu ele alıyor: paylaşımlı ya da reseller bir cPanel hesabı; veya sizin yönettiğiniz 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, yedekleri nesne olarak saklamak için kullanılabilir. 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 hizmetin desteğine ve ayarlarına bağlı olarak sürümleme kullanabiliyorsunuz. Yedekleriniz bir bucket içinde tutuluyor ve HTTP tabanlı bir API ile erişiliyor.

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

• Kapasite: Yerel diskten bağımsız büyüyebilir; kota ve maliyet seçilen hizmete bağlıdır.
• Dayanıklılık: Replikasyon ve arıza alanlarını hizmet belgesinden doğrulayın; tek düğümlü bir kurulum çoklu bölge koruması sağlamaz.
• Sürümleme: Desteklenip etkinleştirilmişse eski nesne sürümlerini saklayabilir; silme yetkisi ve eski sürüm politikaları ayrıca önemlidir.
• Lifecycle: Bağımsız tam arşivlerin saklama politikasında kullanılabilir. Restic deposundaki yaşlı nesneler güncel snapshot’larca kullanılabilir; bunları S3 yaş kuralıyla silmeyin veya erişilemeyen sınıfa taşımayın.

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:

• Tamamlanmış cPanel .tar.gz hesap arşivlerini ayrı uzak öneklere copy ile göndermek.
• Kaynak ve hedef farkını denetlemek; hedefte bağımsız saklanacak kopyalar için silmeli senkronizasyon kullanmamak.
• Gerekirse rclone crypt ile istemci tarafında şifreleme eklemek ve anahtar kurtarmayı ayrıca test etmek.

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:

• Şifreleme: Depodaki yedek içeriğini istemci tarafında şifreler; sunucunun ele geçirilmesi veya parolanın kaybı risklerini ortadan kaldırmaz.
• Artımlı depolama: Tekrarlanan veri parçalarını yeniden kullanabilir. Tasarruf veri türüne ve değişime bağlıdır.
• Snapshot: Bir yedek çalışması bir geri dönüş noktası üretir; kısmi/hatalı çalışma ayrıca izlenmelidir.
• S3: Desteklenen S3 uyumlu endpoint’e rclone gerektirmeden bağlanabilir.

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:

• Gecelik hesap arşivi üretme, tamamlandığını doğrulama ve kopyalamayı tek görevde sıraya koyabilirsiniz.
• Örneğin 4 saatte bir yeni ve tamamlanmış dump ile dosya snapshot’ı alabilirsiniz; bu süre bir RPO garantisi değildir.
• Ayrı bakım penceresinde saklama politikasını önce önizleyip sonra uygulayabilirsiniz.

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?

Üç model karşılaştırılabilir. 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’in tamamlanmış sıkıştırılmış hesap arşivini rclone ile benzersiz bir Object Storage önekine kopyalarsınız. Her arşiv bağımsız tam kopyadır; değişen parçaları depolama avantajı yoktur.

• Yapı basittir, hata ayıklaması kolaydır.
• Tam hesap arşivinin otomatik geri yüklemesi WHM üzerinden yetkili yönetici veya hosting sağlayıcısıyla yapılır. Kullanıcı cPanel arayüzündeki kısmi yedek geri yüklemesi farklıdır; tam arşivden yalnızca public_html dosyalarını çıkarmak hesabın tamamını geri getirmez. Gerekli yetkiyi ve tam geri yükleme yolunu yedek planında önceden doğrulayın.

Model 2: Sadece restic ile Artımlı Yedek

Restic ile web kökünü, tamamlanmış veritabanı dump’ını ve gerekli yapılandırmaları yedekleyebilirsiniz. Bu dosya geçmişi, cPanel’in hesap metadatasını içeren yerel tam arşivinin veya yeniden kurulum planının yerine geçmez.

• Artımlı ve deduplikasyonlu yapı, yedekler arasında tekrar eden veri miktarına bağlı olarak alan tasarrufu sağlayabilir.
• Tek dosya yerine snapshot tabanlı anlaşılır bir yapı sunar.
• Varsayılan şifreleme, yedeklerin gizliliğini korumaya yardımcı olur; tek başına KVKK/GDPR uyumluluğu sağlamaz.

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

Tam hesap kurtarma ve daha sık dosya geçmişi birlikte gerekiyorsa iki akışı ayrı öneklerde kullanabilirsiniz:

• 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 ve veritabanı dump’ları yedeklenir. Bu sıklık veri kaybı aralığını azaltmayı hedefler; geri dönüş süresi ayrıca ölçülmelidir.

Aşağıdaki hibrit örnekten yalnızca ihtiyacınız olan akışları kurun. Aynı kaynakta bağımsız WHM zamanlayıcısı ve bu betikleri yarıştırmayın; ortak kilit yalnızca aynı kilidi kullanan yerel görevleri koordine eder.

Adım 1: Yedek Dizinlerini Hazırlama ve Kullanıcı Seçimi

İlk iş, yedeklerin yerelde nereye ineceğini ve hangi kullanıcıyla çalışacağını belirlemek. Aşağıdaki dizin, /root dosyaları ve cron örnekleri root kullanıcısını; kabuk komutları Bash kullanımını varsayar.

• Örnekler /opt/backups kullanır; kaynaklar, ara dosyalar ve geri yükleme testleri için boş alan ölçün.
• cPanel pkgacct için resmî belge, kaynak ve hedefte en büyük hesabın iki katından fazla alan ve ek 1 GB gerektirir; mevcut paketler ve loglar bunun üzerine eklenir.

umask 077
install -d -m 700 /opt/backups /opt/backups/db-dumps /opt/backups/status /opt/backups/cpanel

Yedekleme için ayrı, sınırlı izinlere sahip bir sistem kullanıcısı seçerseniz dizin sahipliğini, kaynak dosyaları okuma izinlerini, erişim bilgilerini ve cron görevlerini buna göre uyarlamanız gerekir. Bu rehberdeki örnekler bu ayrımı kurmaz. Tek hesap için cPanel panelinden tam yedek üretmek ile WHM üzerinden sunucu çapında yedek yönetmek farklı yetki kapsamlarıdır.

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

rclone Kurulumu

Resmî indirmeler 4 Kasım 2026’da kontrol edildi: rclone 1.75.2 ve restic 0.19.1. Aşağıdaki sabit sürüm örnekleri yalnızca Linux amd64 içindir. Boş bir dizin, curl, unzip, bzip2 ve sha256sum gerekir. Farklı mimari/sürüm için kendi resmî paketini ve checksum’unu seçin; sürüm numarasını tek başına değiştirmeyin.

(
    set -euo pipefail
    rclone_version=1.75.2
    curl -fLO "https://downloads.rclone.org/v${rclone_version}/rclone-v${rclone_version}-linux-amd64.zip"
    printf '%s  %s\n' '349ac8fba6ff65d6247043f1750cdcb518ec5d500ef91463a10d37c0ccdf3702' \
        "rclone-v${rclone_version}-linux-amd64.zip" | sha256sum -c -
    unzip "rclone-v${rclone_version}-linux-amd64.zip"
    install -m 755 "rclone-v${rclone_version}-linux-amd64/rclone" /usr/local/bin/rclone
    /usr/local/bin/rclone version
)

Dağıtımın desteklediği uygun paketleri de kullanabilirsiniz. Sonraki betikler Bash, flock, gzip ve jq gerektirir; bunları dağıtımın paket yöneticisiyle kurup cron kullanıcısının PATH’inde doğrulayın.

S3 Uyumlu Uzak Depolama Tanımı

Şimdi rclone’a kullandığınız S3 uyumlu servisin erişim bilgilerini tanıtalım. Yapılandırmayı cron görevini çalıştıracak kullanıcıyla oluşturun:

rclone config

Sonra adım adım:

1. Yeni uzak bağlantıya backup-s3 adını verin; depolama türünü s3 seçin.
2. Sağlayıcı listeleniyorsa onu, genel S3 uyumlu hizmet için Other seçeneğini kullanın.
3. Endpoint, region, kimlik doğrulama, ACL ve depolama sınıfı ayarlarını sağlayıcının belgelerine göre girin. https://objects.example.com gerçek hizmet adresi değildir.
4. Önceden oluşturduğunuz bucket komut yolunda yer alır: backup-s3:company-backups/cpanel. Yedek ve restic öneklerini ayrı tutun; mevcut restic nesnelerine yaşa bağlı otomatik silme uygulamayın.

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

rclone lsf backup-s3:company-backups --max-depth 1

Boş bucket boş çıktı verebilir; çıkış kodu yine 0 olmalıdır. Listeleme testi yazma/okuma yetkisinin tamamını kanıtlamaz. Ayrı test önekine küçük dosya kopyalayıp rclone check --download ile okuyarak doğrulayın; hesap anahtarına yalnızca gerekli bucket/önek yetkilerini verin.

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

restic Kurulumu

(
    set -euo pipefail
    restic_version=0.19.1
    curl -fLO "https://github.com/restic/restic/releases/download/v${restic_version}/restic_${restic_version}_linux_amd64.bz2"
    printf '%s  %s\n' 'f415415624dcc452f2a02b8c33641791a8c6d6d3b65bbb3543fcf9a25151585c' \
        "restic_${restic_version}_linux_amd64.bz2" | sha256sum -c -
    bzip2 -dk "restic_${restic_version}_linux_amd64.bz2"
    install -m 755 "restic_${restic_version}_linux_amd64" /usr/local/bin/restic
    /usr/local/bin/restic version
)

Checksum, indirilen arşivin bütünlüğünü doğrular; kurulumdan sonra sürüm çıktısını da kontrol edin. Buradaki test kapsamı yerel rclone/restic akışlarıdır; seçtiğiniz S3 hizmetinin yetki, TLS ve performans davranışını kendi test bucket’ınızda doğrulayın.

restic Ortam Değişkenleri

VPS için /root/restic-vps.env, cPanel dosya geçmişi için ayrı /root/restic-cpanel.env kullanın. Dosyaları root sahipliği ve 600 izinle oluşturup aşağıdaki yer tutucuları gerçek bilgilerinizle düzenleyin. Her depo için ayrı, güçlü parola dosyası hazırlayın; parolanın güvenli kurtarma kopyasını bu sunucudan ayrı saklayın. Örnek adres ve anahtarlarla üretim işi başlatmayın.

export RESTIC_REPOSITORY='s3:https://objects.example.com/company-backups/restic-vps'
export RESTIC_PASSWORD_FILE='/root/restic-vps.password'
export AWS_ACCESS_KEY_ID='REPLACE_WITH_ACCESS_KEY'
export AWS_SECRET_ACCESS_KEY='REPLACE_WITH_SECRET_KEY'
export BACKUP_HOST='server01'

Bu içerik /root/restic-vps.env dosyasına aittir. Parola dosyası tek satırlık gerçek depo parolasını içerir. Mevcut dosyaları ezmeden oluşturun ve erişimi doğrulayın:

chown root:root /root/restic-vps.env /root/restic-vps.password
chmod 600 /root/restic-vps.env /root/restic-vps.password

Buradaki AWS_ACCESS_KEY_ID adı, mutlaka AWS kullanmanız gerektiği anlamına gelmez; örnek, S3 erişim bilgilerini bu değişkenlerle tanımlar. Seçtiğiniz servisin restic ile uyumluluğunu ayrıca doğrulayın.

restic Deposu Oluşturma

source /root/restic-vps.env
restic init

Yalnızca yeni ve doğru depo öneki için bir kez çalıştırın. Var olan depoda restic snapshots ile bağlantıyı doğrulayın. Parola kaybı, sağlam nesnelere sahip olsanız bile geri yüklemeyi engeller.

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.

Aşağıdaki otomatik örnek, WHM zamanını tahmin etmek yerine root yetkili pkgacct işlemini aynı görev içinde bekler. /root/cpanel-archive.env dosyasını root:root ve 600 izinle hazırlayın. Mevcut WHM yedekleme akışını tercih ediyorsanız tamamlanma olayını, değişmeyen kaynak arşivini ve ürünün desteklediği hedefleri ayrı doğrulayın; artımlı ham dizini S3’e kopyalamak tam hesap geri yüklemesini kanıtlamaz.

ARCHIVE_REMOTE='backup-s3:company-backups/cpanel'
BACKUP_HOST='server01'

Tamamlanan Arşivi Silmeden Kopyalama

/opt/backups/cpanel-backup.sh dosyasına aşağıdaki içeriği koyun; root:root sahipliği ve 700 izin verin. Betik hesabı doğrular, yerel kilidi alır, yeni çalışma dizininde sıkıştırılmış arşivi üretir, çıkış durumunu/tamamlanma işaretini ve gzip bütünlüğünü kontrol eder; ardından kopyayı okuyarak karşılaştırır. Arşiv işaretinin kurulu cPanel sürümünüzle uyumunu ilk denemede kontrol edin.

#!/usr/bin/env bash
set -euo pipefail
umask 077
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
account=${1:?Usage: cpanel-backup.sh CPANEL_ACCOUNT}
[[ "$account" =~ ^[a-z][a-z0-9_]{0,15}$ ]] || exit 64
[[ -f "/var/cpanel/users/$account" ]] || exit 66
source /root/cpanel-archive.env
: "${ARCHIVE_REMOTE:?}" "${BACKUP_HOST:?}"
[[ "$BACKUP_HOST" =~ ^[A-Za-z0-9._-]+$ ]] || exit 64
exec 9>/opt/backups/.backup.lock
flock -n 9 || { printf 'Backup lock is busy.\n' >&2; exit 75; }
install -d -m 700 /opt/backups/cpanel /opt/backups/status
work=$(mktemp -d /opt/backups/cpanel/.run.XXXXXX)
trap 'printf "Local run directory retained: %s\n" "$work" >&2' EXIT
install -d -m 700 "$work/package" "$work/ready"
/usr/local/cpanel/scripts/pkgacct --backup --dbbackup=all \
    "$account" "$work/package" > "$work/pkgacct.log" 2>&1
if ! grep -qF 'pkgacct completed' "$work/pkgacct.log"; then
    printf 'No successful pkgacct completion marker; inspect %s\n' "$work/pkgacct.log" >&2
    exit 65
fi
archive="$work/package/$account.tar.gz"
[[ -s "$archive" ]] || exit 66
gzip -t "$archive"
mv -- "$archive" "$work/ready/$account.tar.gz"
run_id="$(date -u +%Y%m%dT%H%M%SZ)-${work##*.}"
destination="${ARCHIVE_REMOTE%/}/$BACKUP_HOST/$account/$run_id"
rclone copy "$work/ready" "$destination" --immutable \
    --transfers=1 --checkers=2 --bwlimit=5M
rclone check "$work/ready" "$destination" --download --one-way
state=$(mktemp /opt/backups/status/.cpanel-state.XXXXXX)
printf '%s %s\n' "$(date -u +%FT%TZ)" "$destination" > "$state"
mv -f -- "$state" "/opt/backups/status/cpanel-$account-last-success"
printf 'Verified archive destination: %s\n' "$destination"

Burada:

• copy kaynakta bulunmayan eski hedefleri silmez; --immutable farklı mevcut dosyayı değiştirmek yerine hata verir. sync --delete-after ve --delete-excluded bağımsız saklama sağlamaz.
• --bwlimit=5M örnek sınırdır; ölçülen bağlantı ve üretim yüküne göre uyarlayın. Okuyarak karşılaştırma indirme/API maliyeti doğurur.
• Başarı/hata çalışma dizinleri loglarıyla yerelde tutulur. Doğrulanmış uzak kopyalar ve kurtarma hedeflerinize göre ayrı yerel temizlik planı oluşturun; aksi halde disk dolar. Uzak tam arşiv saklama politikasını restic deposundan ayrı yönetin.
• Tam arşiv bütünlüğü uygulama kurtarmasını tek başına kanıtlamaz. cPanel 2FA yapılandırmasını aktarmayabilir; kaynak/hedef sürüm uyumu ve yeniden yapılandırılacak öğeleri geri yükleme planına yazın.

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

WHM’nin 02:00’de başlaması 03:00’te bitmesini garanti etmez. Bu örnekte tek betik üretimden doğrulamaya kadar bağımlılıkları uygular; önce manuel çalıştırıp test ortamında geri yükleyin. Farklı sunucular veya yerel kilidi kullanmayan WHM görevleri ayrıca koordine edilmelidir.

crontab -e

Yalnızca bu akışı kullanıyorsanız root crontab’a ekleyin; CPANEL_ACCOUNT yerine gerçek hesabı yazın:

0 3 * * * /opt/backups/cpanel-backup.sh CPANEL_ACCOUNT >> /var/log/cpanel-backup.log 2>&1

03:00 sunucunun cron saat dilimidir. Çıktı dosyaya yönlendiği için cron e-postası hata bildirimini sağlamaz. Çıkış durumunu ve /opt/backups/status/cpanel-HESAP-last-success yaşını izleyin; kilit dolu olduğunda kod 75 ile atlanan çalışma da beklenen başarı aralığına dahil edilmelidir.

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

Aşağıdaki yardımcı /opt/backups/db-dump.sh olarak kaydedilir; ayrı cron işi değildir, kilidi alan ana betik tarafından çağrılır. /root/backup-database.env içinde MySQL için DB_FLAVOR=mysql, MariaDB için mariadb ve gerçek uygulama veritabanı adlarını seçin. /root/backup-mysql.cnf dosyasında [client] kullanıcı/parolasını veya desteklenen socket kimlik doğrulamasını kurun; iki dosya root:root/600 olmalıdır. Dump kullanıcısının seçilen tablolar, view, rutin, olay ve trigger yetkilerini test edin.

DB_FLAVOR=mysql
DB_DEFAULTS_FILE=/root/backup-mysql.cnf
DB_NAMES=(application_db)

[client]
user=backup_user
password=REPLACE_WITH_DATABASE_PASSWORD

#!/usr/bin/env bash
# Source this file from a backup job holding /opt/backups/.backup.lock.
make_database_dump() (
    set -euo pipefail
    umask 077
    source /root/backup-database.env
    : "${DB_FLAVOR:?}" "${DB_DEFAULTS_FILE:?}"
    (( ${#DB_NAMES[@]} > 0 )) || exit 64
    [[ -r "$DB_DEFAULTS_FILE" ]] || exit 66
    for database in "${DB_NAMES[@]}"; do
        [[ "$database" =~ ^[A-Za-z0-9_]+$ ]] || exit 64
    done
    case "$DB_FLAVOR" in
        mysql) dump_command=mysqldump; extra=(--set-gtid-purged=OFF) ;;
        mariadb) dump_command=mariadb-dump; extra=() ;;
        *) printf 'Set DB_FLAVOR to mysql or mariadb.\n' >&2; exit 64 ;;
    esac
    dump_dir=/opt/backups/db-dumps
    install -d -m 700 "$dump_dir"
    partial=$(mktemp "$dump_dir/.databases.sql.gz.XXXXXX")
    trap 'rm -f -- "$partial"' EXIT
    "$dump_command" --defaults-extra-file="$DB_DEFAULTS_FILE" \
        --single-transaction --quick --routines --events --triggers \
        --no-tablespaces "${extra[@]}" --databases "${DB_NAMES[@]}" \
        | gzip > "$partial"
    gzip -t "$partial"
    mv -f -- "$partial" "$dump_dir/databases.sql.gz"
)

--single-transaction tutarlılığı InnoDB gibi işlem destekleyen tablolara bağlıdır; MyISAM/MEMORY için garanti vermez. Dump boyunca ALTER/CREATE/DROP/RENAME/TRUNCATE çalıştırmayın. MySQL örneğinde GTID aktarımı kapalıdır; bu, replikasyon/PITR kurulumunun yerine geçmez. MariaDB ayrı istemci kullanır. Kullanıcılar, genel tablespace tanımları, seçilmemiş veritabanları ve sunucu düzeyi metadatayı bu dump’ın kapsadığını varsaymayın. PostgreSQL veya fiziksel yedek için uygun aracın tutarlı yedekleme akışını ayrıca kurun.

Yardımcı dosyayı root:root/600 koruyun. Örnek, veritabanı adlarında yalnızca harf, rakam ve alt çizgiyi kabul eder; farklı adlar varsa doğrulama kuralını kontrollü biçimde uyarlayın. Ham MySQL veri dizini bu tamamlanmış mantıksal dump ile aynı şey değildir.

restic ile Dosya + Veritabanı Snapshot’ı

/opt/backups/restic-backup.sh dosyasına aşağıdaki kodu yazın; root:root/700 yapın. Ana betik kilit altında dump’ı üretir, ardından /var/www, /etc ve yalnızca tamamlanmış dump dosyasını yedekler. Gerçek kaynakları ve sembolik bağlantı hedeflerini envanterleyin: restic bağlantıyı saklar, hedefini izlemez. Canlı dosyalar ve SQL kendiliğinden aynı ana ait olmaz; uygulamaya göre yazmayı durdurma veya tutarlı snapshot süreci gerekir.

#!/usr/bin/env bash
set -euo pipefail
umask 077
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
exec 9>/opt/backups/.backup.lock
flock -n 9 || { printf 'Backup lock is busy.\n' >&2; exit 75; }
source /root/restic-vps.env
source /opt/backups/db-dump.sh
: "${BACKUP_HOST:?}"
[[ -d /var/www && -d /etc ]] || exit 66
install -d -m 700 /opt/backups/status
result=$(mktemp /opt/backups/status/.vps-result.XXXXXX)
state=$(mktemp /opt/backups/status/.vps-state.XXXXXX)
trap 'rm -f -- "$result" "$state"' EXIT
make_database_dump
restic backup /var/www /etc /opt/backups/db-dumps/databases.sql.gz \
    --host "$BACKUP_HOST" --tag vps-app --json > "$result"
snapshot_id=$(jq -er 'select(.message_type == "summary") | .snapshot_id' "$result")
[[ "$snapshot_id" =~ ^[0-9a-f]{64}$ ]] || exit 65
printf '%s %s\n' "$(date -u +%FT%TZ)" "$snapshot_id" > "$state"
mv -f -- "$state" /opt/backups/status/vps-last-success
cat "$result"

Buradaki saklama politikasını kendi RPO/RTO hedeflerinize göre düzenleyebilirsiniz. Daha sık snapshot almak için cron zamanlamasını değiştirmeniz gerekir; saklama değerlerini artırmak yedek alma sıklığını artırmaz. Gün içindeki geri dönüş noktalarının ne kadar süre korunacağını da ayrıca belirleyin. 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.

Başarılı çalışma UTC zamanını ve tam snapshot ID’sini kaydeder; restic’in kısmi yedek kodu 3 dahil sıfır olmayan sonuçlar bu kaydı güncellemez. Yerel durum dosyasının kaybına karşı izleme/runbook kaydını ayrı tutun. Opsiyonel cPanel dosya geçmişi için ayrı /root/restic-cpanel.env kullanın; aynı dosyayı VPS ayarlarının üzerine yazmayın:

export RESTIC_REPOSITORY='s3:https://objects.example.com/company-backups/restic-cpanel'
export RESTIC_PASSWORD_FILE='/root/restic-cpanel.password'
export AWS_ACCESS_KEY_ID='REPLACE_WITH_ACCESS_KEY'
export AWS_SECRET_ACCESS_KEY='REPLACE_WITH_SECRET_KEY'
export BACKUP_HOST='server01'

Ayrı parola dosyasını hazırlayıp iki dosyayı root:root/600 yapın; bu depoyu bir kez başlatın. Aşağıdaki içerik /opt/backups/restic-cpanel-backup.sh dosyasına root:root/700 olarak kaydedilir. /home, /etc, /var/named ve tamamlanmış dump’ı kapsar; cPanel tam hesap arşivi yerine geçmez. Veritabanı listesini bu hesaplara göre açıkça seçin.

source /root/restic-cpanel.env
restic init

#!/usr/bin/env bash
set -euo pipefail
umask 077
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
exec 9>/opt/backups/.backup.lock
flock -n 9 || { printf 'Backup lock is busy.\n' >&2; exit 75; }
source /root/restic-cpanel.env
source /opt/backups/db-dump.sh
: "${BACKUP_HOST:?}"
[[ -d /home && -d /etc && -d /var/named ]] || exit 66
install -d -m 700 /opt/backups/status
result=$(mktemp /opt/backups/status/.cpanel-files-result.XXXXXX)
state=$(mktemp /opt/backups/status/.cpanel-files-state.XXXXXX)
trap 'rm -f -- "$result" "$state"' EXIT
make_database_dump
restic backup /home /etc /var/named /opt/backups/db-dumps/databases.sql.gz \
    --host "$BACKUP_HOST" --tag cpanel-files --json > "$result"
snapshot_id=$(jq -er 'select(.message_type == "summary") | .snapshot_id' "$result")
[[ "$snapshot_id" =~ ^[0-9a-f]{64}$ ]] || exit 65
printf '%s %s\n' "$(date -u +%FT%TZ)" "$snapshot_id" > "$state"
mv -f -- "$state" /opt/backups/status/cpanel-files-last-success
cat "$result"

Saklamayı Ayrı Bakım Görevinde Yönetme

/opt/backups/restic-maintenance.sh olarak root:root/700 kaydedin. Önce önizlemeyi inceleyin; apply eski snapshot’ları siler ve kullanılmayan veriyi temizler. Son 7 günlük aralık, grubun en yeni snapshot’ına göredir ve gün içi noktalarını da korur; günlük/haftalık/aylık kuralların birleşimi toplam sayıyı belirler. Host, yol ve tag değişimleri ayrı grup oluşturabilir. Saklama sayısını artırmak yedekleme sıklığını artırmaz.

#!/usr/bin/env bash
set -euo pipefail
umask 077
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
case "${1:-}" in
    vps) source /root/restic-vps.env; backup_tag=vps-app ;;
    cpanel) source /root/restic-cpanel.env; backup_tag=cpanel-files ;;
    *) printf 'Usage: restic-maintenance.sh vps|cpanel [apply]\n' >&2; exit 64 ;;
esac
: "${BACKUP_HOST:?}"
exec 9>/opt/backups/.backup.lock
flock -n 9 || { printf 'Backup lock is busy.\n' >&2; exit 75; }
policy=(--host "$BACKUP_HOST" --tag "$backup_tag" --group-by host,paths,tags
        --keep-within 7d --keep-daily 7 --keep-weekly 4 --keep-monthly 6)
case "${2:-preview}" in
    preview) restic forget "${policy[@]}" --dry-run ;;
    apply) restic forget "${policy[@]}" --prune ;;
    *) exit 64 ;;
esac

/opt/backups/restic-maintenance.sh vps
# Review first; this next command deletes expired snapshots:
/opt/backups/restic-maintenance.sh vps apply

cPanel deposu için ilk argümanı cpanel yapın. Prune özel depo kilidi gerektirir; başka sunuculardaki işleri de koordine edin. Planlı aralıklarla restic check, uygun indirme bütçesiyle restic check --read-data çalıştırın; ilk komut bütün veri paketlerini okumaz. S3 yaş kurallarıyla restic nesnelerini silmeyin.

restic Yedekleri için Cron

Aşağıdaki örnek görevi 4 saatte bir tetikler. Aralığı RPO hedefinize ve ölçülen yedekleme süresine göre seçin; önceki çalışmanın bitmeden yenisinin başlamasını engelleyin. root crontab’a:

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

Bu satır görevi dört saatte bir başlatır; başarı süresi ve hedef RPO ölçülmelidir. cPanel dosya akışını seçtiyseniz ayrı betik yolunu kullanın ve diğer işlerle çakışmayacak zamanı seçin. root yolları kullanıcı düzeyi cPanel Cron Jobs ekranından çalışmaz. WHM Configure cPanel Cron Jobs yalnızca upcp/backup/cpbackup zamanlarını yönetir; genel root görevleri root crontab’a aittir.

Gereksiz veriyi dışlarken gerçek kurtarma kapsamını koruyun. --exclude-caches yalnızca CACHEDIR.TAG işaretli dizinleri tanır; --one-file-system iç içe bağlama noktalarını atlayabilir. Hariç tutma kurallarını test etmeden eklemeyin.

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:

• Düşük yoğunluklu zamanı ve aktarım sınırını ölçümle seçin.
• Kurulu sistemin desteklediği nice/ionice öncelikleri yardımcı olabilir; kaynak sınırı veya performans garantisi değildir. Aşağıdaki komut aynı kilitli VPS işini çalıştırır.

nice -n 10 ionice -c2 -n7 /opt/backups/restic-backup.sh

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:

• Ayrı bucket/önek ve gerekli işlem yetkilerini kullanın; yazma, okuma, listeleme ve bakım silme ihtiyaçlarını test edin.
• Env, parola ve rclone config dosyalarını root:root/600 koruyun; gerçek config konumunu rclone config file ile kontrol edin.
• Restic şifrelemesi erişim kontrolünün yerine geçmez. Düz arşiv için crypt veya uygun başka şifreleme planlayın; anahtar kurtarmayı sınayın.
• Sağlayıcı destekliyorsa sürümleme, server-side encryption veya Object Lock değerlendirilebilir. Silme koruması, restic kilit/prune davranışı ve kurtarma uyumluluğu test edilmeden etkinleştirilmiş koruma varsaymayı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:

• Görev çıkış koduna ve en son başarılı çalışmanın yaşına alarm bağlayın; yalnızca logun son satırını kontrol etmek yeterli değildir.
• Beklenen host/tag için snapshot ID’sini ve cPanel arşiv hedefini izleme sisteminde ayrı kaydedin.
• Cron mail için teslimat yapılandırması gerekir; dosyaya yönlenen çıktılar otomatik olarak e-posta olmaz. Alarm kanalını kontrollü başarısızlıkla test edin.

Hata alarmının yanında geciken/atlanmış yedeği ve dolan diski de izleyin. Böylece bozuk iş veya durmuş zamanlayıcı, sırf logda önceki başarı duruyor diye sağlıklı görünmez.

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:

• Riskinize göre düzenli prova planlayın; aylık prova başlangıç olabilir, kritik sistemlerde daha sık doğrulama gerekebilir.
• Tam cPanel hesabını WHM üzerinden yetkili yönetici/sağlayıcıyla ayrı test sunucusuna geri yükleyin. cPanel’in kısmi geri yüklemesi veya public_html çıkarmak tam hesap kurtarma değildir.
• Kayıtlı başarılı snapshot ID’sini seçin; dosyalar, izinler, uygulama oturumu, veritabanı, e-posta ve DNS/SSL ihtiyaçlarını kontrol edin.
• Test ortamında gerçek e-posta, ödeme ve webhook çıkışlarını kapatın. SQL içindeki CREATE DATABASE/USE adlarını inceleyip yalnızca izole test sunucusunda uygun istemciyle içe aktarın. MariaDB dump’larının sandbox komutu eski MariaDB/MySQL istemcileriyle uyumsuz olabilir.

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.

(
    set -euo pipefail
    umask 077
    source /root/restic-vps.env
    restic snapshots --host "$BACKUP_HOST" --tag vps-app
    read -r completed_at snapshot_id < /opt/backups/status/vps-last-success
    [[ "$snapshot_id" =~ ^[0-9a-f]{64}$ ]] || exit 65
    restore_dir=$(mktemp -d /opt/backups/restore.XXXXXX)
    chmod 700 "$restore_dir"
    restic restore "$snapshot_id" --target "$restore_dir"
    printf 'Restore directory: %s\n' "$restore_dir"
)

Bu komut seçilen snapshot’ın tamamını yeni özel dizine çıkarır. Tek site için önce restic ls SNAPSHOT_ID ile yolları inceleyip --include filtresini buna göre seçin; --path dosya filtresi değildir. Sunucu kaybolmuşsa yerel durum dosyası yerine ayrı runbook kaydından ve restic snapshots listesinden açık ID seçin. latest kısmi veya yanlış işin snapshot’ını seçebileceğinden otomatik kullanmayın.

DCHost Tarafında Bu Mimarinin Nereye Oturduğu

Bu yaklaşım DCHost veya başka bir sağlayıcıda yönettiğiniz cPanel, VPS, fiziksel sunucu ve colocation iş yüklerine uyarlanabilir. Yedek hizmetinin dahil olduğunu ya da belirli bir Object Storage endpoint’inin sunulduğunu varsaymayın; mevcut hizmet kapsamını ve erişim yetkilerini doğrulayın.

• Tek VPS için dosya/SQL kapsamı, depolama maliyeti ve kurtarma süresi ölçülür.
• Birden çok cPanel hesabında hesap başına arşiv ve erişim ayrımı korunur; arşivler paralel görevlerle aynı kaynağı zorlamamalıdır.
• Fiziksel sunucu veya colocation için farklı arıza alanında hedef seçilir; bölge, ağ ve kurtarma kapasitesi plana dahil edilir.

Kuruluma kaynak envanteri ve hedef RPO/RTO ile başlayın. Küçük bir pilotta arşiv/dump üretimini, uzak doğrulamayı, hata alarmını ve geri yüklemeyi tamamlayın; ardından zamanlamayı ve saklamayı iş yükünüze göre genişletin.

Sağlam bir Object Storage yedekleme akışında kopyalama, tamamlanmış veri üretimi, şifreleme, saklama ve geri yükleme ayrı ayrı doğrulanır. Rclone arşivleri taşır; restic dosya geçmişini yönetir; cron bu denetlenmiş işleri başlatır. Başarı ölçütü test edilmiş kurtarma noktasıdır.

Resmî Kaynaklar

• cPanel: pkgacct
• cPanel: Backup
• rclone: S3
• rclone: copy and check
• restic: backup
• restic: retention
• restic: restore
• MySQL 8.4: mysqldump
• MariaDB: mariadb-dump