Müşteri yedeği ne sıklıkla alınmalı?

Çoğu bayi hosting müşterisi için günlük otomatik yedek makul bir başlangıçtır. Sık güncellenen e-ticaret gibi hesaplar için daha sık veritabanı yedeği ayrıca sunulabilir; sıklık, politikanızda ve paket açıklamasında açıkça yazılmalıdır.

Sağlayıcı yedeği müşterinin kendi yedeğinin yerine geçer mi?

Genellikle hayır. Sağlayıcı yedeği sunucu çapında felaket kurtarma için tasarlanır; müşteri kritik verileri için kendi yedeğini de almalıdır. Bu ayrımı sözleşmede ve politika metninde belirtmek beklentileri netleştirir.

Yedeklerin çalıştığını nasıl kanıtlarım?

Yalnızca yedeğin alındığına bakmak yetmez; düzenli aralıklarla rastgele bir hesabı geçici dizine geri yükleyip içeriği açın ve restic check çalıştırın. Bu testin tarihini ve sonucunu kaydetmek, politikanızın güvenilirliğini belgeler.

Bayi hosting için müşteri yedekleme politikası ve geri…

SunucuGüvenlik

Ara…Ctrl K

Menü

2. restic kurulumu ve deponun hazırlanması

restic şifreli ve tekilleştirilmiş yedek alır; RHEL tabanlı sistemlerde paket EPEL deposundadır.

bash

# Debian / Ubuntu
sudo apt install restic

# AlmaLinux / Rocky
sudo dnf install epel-release
sudo dnf install restic

Depo parolasını dosyaya yazın ve yalnızca root okuyabilsin. Parolayı komut satırında göstermeyin; bu dosyayı güvenli bir parola yöneticisinde de saklayın, çünkü kaybolursa yedekler açılamaz.

bash

sudo install -d -m 700 /root/yedek
sudo sh -c 'umask 077; openssl rand -base64 32 > /root/yedek/restic-parola'
sudo chmod 600 /root/yedek/restic-parola
sudo restic init --repo /mnt/yedek/restic --password-file /root/yedek/restic-parola

Burada /mnt/yedek, ayrı diskinize veya uzak bağlantı noktanıza bağlı dizindir.

3. Veritabanı dökümünü alın

Çalışan bir veritabanının dosyalarını doğrudan kopyalamak tutarsız yedek üretebilir. Mantıksal döküm alın; döküm dosyalarını yalnızca root okuyabilsin. Kimlik bilgilerini komut satırında yazmak yerine root için korumalı bir seçenek dosyası kullanın.

bash

sudo sh -c 'umask 077; mkdir -p /var/backups/db'
sudo sh -c 'umask 077; mysqldump --single-transaction --routines --events --all-databases | gzip > /var/backups/db/tum-veritabanlari.sql.gz'
ls -lh /var/backups/db/

MariaDB'nin yeni sürümlerinde mariadb-dump komutu da kullanılabilir. Root için unix_socket kimlik doğrulaması açıksa komut ek parola gerektirmez; değilse /root/.my.cnf dosyasında kimlik bilgilerini tutun ve chmod 600 uygulayın. Müşteri bazlı geri yükleme kolaylığı için veritabanlarını tek tek dökmek de iyi bir yöntemdir.

4. Yedeği alın ve zamanlayın

Aşağıdaki betik önce veritabanı dökümünü alır, ardından web verileri, posta kutuları ve dökümleri restic ile depoya gönderir. Dizin yollarını kendi düzeninize göre uyarlayın.

bash

sudo tee /usr/local/sbin/musteri-yedek.sh >/dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
umask 077
mysqldump --single-transaction --routines --events --all-databases | gzip > /var/backups/db/tum-veritabanlari.sql.gz
export RESTIC_REPOSITORY=/mnt/yedek/restic
export RESTIC_PASSWORD_FILE=/root/yedek/restic-parola
restic backup /home /var/backups/db --tag gunluk
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune
EOF
sudo chmod 700 /usr/local/sbin/musteri-yedek.sh

Zamanlamayı systemd zamanlayıcıyla yapın.

ini

# /etc/systemd/system/musteri-yedek.service
[Unit]
Description=Musteri yedekleme

[Service]
Type=oneshot
Environment=HOME=/root
ExecStart=/usr/local/sbin/musteri-yedek.sh
Nice=10
IOSchedulingClass=idle

ini

# /etc/systemd/system/musteri-yedek.timer
[Unit]
Description=Gunluk musteri yedekleme

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=15min
Persistent=true

[Install]
WantedBy=timers.target

bash

sudo systemctl daemon-reload
sudo systemctl enable --now musteri-yedek.timer
sudo systemctl start musteri-yedek.service

IOSchedulingClass=idle ayarı, yedeğin gün içindeki müşteri trafiğini yavaşlatmasını azaltır. HOME satırı, systemd altında /root/.my.cnf ve restic önbelleği için gereklidir.

5. Müşteri talebiyle tek hesabı geri yükleyin

Geri yükleme isteğinde altın kural, mevcut canlı verinin üzerine doğrudan yazmamaktır. Önce geçici bir dizine geri yükleyin, içeriği müşteriyle doğrulayın, ardından kopyalayın. Talep eden kişinin hesap sahibi olduğunu panel üzerinden veya kayıtlı e-posta ile doğrulayın.

bash

export RESTIC_REPOSITORY=/mnt/yedek/restic
export RESTIC_PASSWORD_FILE=/root/yedek/restic-parola
sudo -E restic snapshots
sudo -E restic restore latest --target /root/geri-yukleme --include /home/hesapkullanici
sudo ls -la /root/geri-yukleme/home/hesapkullanici | head

Belirli bir tarihteki durumu istiyorsanız latest yerine restic snapshots çıktısındaki anlık görüntü kimliğini yazın. Veritabanı için döküm dosyasını geçici bir veritabanına yükleyip kontrol edin, sonra müşteri onayıyla gerçek veritabanına aktarın.

Doğrulama

Yedeklemenin çalıştığını üç noktadan doğrulayın. Zamanlayıcı etkin mi ve son çalışma başarılı mı:

bash

systemctl list-timers musteri-yedek.timer
sudo journalctl -u musteri-yedek.service -n 20 --no-pager

Beklenen sonuç: Zamanlayıcının bir sonraki çalışma zamanının listelenmesi ve günlüğün hatasız bitmesidir. Depoda anlık görüntü olduğunu ve bütünlüğünü doğrulayın:

bash

export RESTIC_REPOSITORY=/mnt/yedek/restic
export RESTIC_PASSWORD_FILE=/root/yedek/restic-parola
sudo -E restic snapshots
sudo -E restic check

Beklenen sonuç: snapshots çıktısında güncel tarihli kayıtlar ve check sonunda hata bulunmadığını bildiren bir mesaj. Geri yükleme testinde dosyaların okunabilir ve beklenen içerikte olduğunu da gözle kontrol edin.

Bayi hosting için müşteri yedekleme politikası ve geri yükleme süreci

Bu rehberde ne yapacağız?

Gereksinimler

Adım adım bayi hosting müşteri yedekleme politikası

1. Yedekleme politikasını yazılı hale getirin

2. restic kurulumu ve deponun hazırlanması

3. Veritabanı dökümünü alın

4. Yedeği alın ve zamanlayın

5. Müşteri talebiyle tek hesabı geri yükleyin

Doğrulama

Sık karşılaşılan sorunlar

Güvenlik ve bakım notları

Sık sorulan sorular

İlgili sözlük terimleri

Bu kategorideki diğer rehberler