WordPress Yedekleme Rehberi: Otomatik ve Manuel Yedek Alma

25 Nisan 2026 WPNeta No comments yet

Kısa Özet

WordPress yedeklemesi, site sahibinin sigorta poliçesidir. Sunucu çöker, eklenti güncellemesi ortalığı yıkar, bir tema güncellemesinde özel kodunuz silinir, hatta basit bir kullanıcı hatası üretim ortamında bir sayfayı kalıcı olarak siler — bu senaryoların hiçbiri tek başına bir WordPress yedekleme stratejisi olan site sahibi için kriz değildir. Bu rehberde; otomatik yedekleme eklentileriyle (UpdraftPlus, BlogVault, Jetpack VaultPress, Solid Backups) düzenli yedek almayı, hosting kontrol panelinden (cPanel, Plesk, JetBackup) tam sunucu yedekleri çıkarmayı ve manuel yöntemlerle (SSH, mysqldump, WP-CLI) profesyonel düzeyde tam site yedeği oluşturmayı adım adım göreceksiniz. Ayrıca 3-2-1 yedekleme kuralını, yedekleri güvenli saklamayı, gerçekten test edilmiş bir geri yükleme prosedürünü, sorun giderme adımlarını ve sıkça sorulan soruları kapsıyoruz. Hedef: bir site sahibinin tek başına, panik anında bile saniyeler içinde uygulanabilir bir kurtarma planına sahip olması.

WordPress Yedeklemesi Neden Hayati Önemde?

Bir WordPress sitesi sandığınızdan çok daha fazla bileşenden oluşur: wp-content içindeki temalar, eklentiler ve medya dosyaları, kök dizindeki wp-config.php, .htaccess ve wp-includes/wp-admin klasörleri, MySQL veritabanındaki yazılar, kullanıcılar, yorumlar, ayarlar ve çoğu eklentinin oluşturduğu özel tablolar. Bu bileşenlerden herhangi biri zarar gördüğünde site açılmayabilir. Yedek almak demek, bu bütünün belirli bir andaki tutarlı kopyasını üçüncü bir lokasyonda saklamak demektir.

Yedekleme ihtiyacının tetiklendiği en yaygın olaylar şunlardır: bir eklenti güncellemesinin ardından yaşanan beyaz ekran (WSoD), uyumsuz bir tema yüklemesinin yarattığı PHP fatal error, hatalı bir veritabanı sorgusunun veri kaybı, hosting sağlayıcısında yaşanan donanım arızası, kötü amaçlı yazılım enfeksiyonu (hack), kazara wp_options tablosunda yapılan bir değişiklik veya yeni bir geliştiricinin canlı sunucuda yanlış komut çalıştırması. Bu olayların ortak özelliği geri alınamaz olmalarıdır; çözüm, geri yüklenebilir bir yedektir.

Resmî veriler de yedekleme disiplinini destekler: WordPress.org dokümantasyonu yedeklemeyi her site sahibinin temel sorumluluğu olarak tanımlar ve PHP ya da MySQL güncellemesi öncesinde mutlaka yedek alınmasını önerir. Hosting sağlayıcılarının çoğu tam sunucu yedeği sunsa da bu yedeklerin sıklığı ve saklama süresi sınırlıdır; site sahibi kendi off-site yedeklerine sahip olmadan tam güvende sayılmaz.

Tam Bir WordPress Yedeği Neleri Kapsamalı?

Tam bir yedek dört bileşeni kapsar:

1. Dosya Sistemi

WordPress kök dizinindeki tüm dosyalar yedeğin parçası olmalıdır. Bu dosyalar genellikle şunlardır:

/public_html/
├── wp-admin/
├── wp-content/
│   ├── plugins/
│   ├── themes/
│   ├── uploads/
│   ├── mu-plugins/
│   └── languages/
├── wp-includes/
├── index.php
├── wp-config.php
├── .htaccess
├── robots.txt
└── ...

Bu klasörler arasında en kritik olan wp-content/uploads (tüm medya dosyaları) ve wp-content/plugins ile wp-content/themes dizinleridir. wp-admin ve wp-includes WordPress çekirdeği tarafından yeniden yüklenebilir, ancak özelleştirme yaptıysanız (ki tavsiye edilmez) bu dosyalar da yedeklenmelidir.

2. MySQL/MariaDB Veritabanı

WordPress veritabanı; yazılarınız, kullanıcılarınız, yorumlarınız, menüleriniz, widget yapılandırmaları, eklenti ayarları ve tema seçenekleri gibi tüm dinamik içerikleri tutar. Veritabanı yedeği genellikle .sql uzantılı bir dump dosyasıdır.

3. Yapılandırma Dosyaları

wp-config.php veritabanı kullanıcı adı, şifre, host, tablo öneki ve gizli anahtarları (AUTH_KEY vb.) içerir. .htaccess kalıcı bağlantı (permalink) yapısı, yönlendirmeler ve güvenlik kuralları için zorunludur. Nginx kullanıcısıysanız sunucu blok dosyanızın bir kopyasını da saklayın.

4. Sunucu Tarafı Yapılandırma

PHP sürümü, php.ini ayarları (memory_limit, upload_max_filesize), MySQL sürümü ve cron tanımları çoğu kullanıcı tarafından unutulur. Tam bir kurtarma için bu meta verileri de bir not dosyasında saklamak akıllıcadır.

Yedekleme Stratejisi: 3-2-1 Kuralı

Profesyonel sistem yöneticilerinin altın standardı olan 3-2-1 kuralı şunu söyler:

3 kopya: Bir orijinal ve en az iki yedek bulundurun.
2 farklı medya: Yerel disk + bulut, ya da iki farklı bulut sağlayıcısı gibi farklı depolama tipleri kullanın.
1 off-site: Bir kopya hosting sunucusundan tamamen ayrı bir lokasyonda olsun.

Pratikte bu, “hosting sağlayıcımın günlük yedekleri var” demenin yeterli olmadığı anlamına gelir; çünkü hosting hesabınız tamamen silinirse onların yedekleri de erişilemez hale gelebilir. En az bir kopya Amazon S3, Backblaze B2, Google Drive, Dropbox veya tamamen farklı bir sunucuda olmalıdır.

Yöntem 1: WordPress Yedekleme Eklentisi ile Otomatik Yedekleme

Bir site sahibinin %90’ı için en pratik çözüm, WordPress eklentisi tabanlı otomatik yedeklemedir. Eklentiler hem zamanlanmış (zamanlayıcı) yedekler alır hem de bulut depolamaya gönderir.

UpdraftPlus ile Adım Adım Yedekleme

UpdraftPlus, üç milyondan fazla aktif kurulumla en yaygın ücretsiz yedekleme eklentisidir. Şu adımları izleyin:

Eklenti kurulumu: WordPress yöneticisi → Eklentiler → Yeni Ekle → “UpdraftPlus” araması → Etkinleştir.
Ayarlar: Ayarlar → UpdraftPlus Yedekleri → Ayarlar sekmesi.
Zamanlama: “Files backup schedule” için Daily, “Database backup schedule” için Daily; saklama miktarı retain this many scheduled backups = 14 önerilir.
Uzak depolama: Google Drive, Dropbox, Amazon S3, Backblaze B2, OneDrive veya FTP seçin. Ücretsiz plan birden çok hedef desteklemez; çok katmanlı yedek için Premium gereklidir.
Yedekleme içeriği: “Plugins”, “Themes”, “Uploads”, “Others” ve “Database” — hepsi işaretli olmalı.
İlk yedek: Mevcut Durum sekmesinden “Backup Now” → tüm seçenekleri işaretleyip onaylayın.

UpdraftPlus, yedekleri zip dosyaları olarak wp-content/updraft/ dizinine yazar, sonra uzak depolamaya yükler. Yerel zip dosyalarını sunucuda silmeden bırakmak disk alanını şişirir; “After-backup” ayarından “Delete its local copy” işaretlenmelidir.

BlogVault, Jetpack VaultPress ve Solid Backups Karşılaştırması

Yedekleme eklentisi seçimi sitenizin büyüklüğüne ve risk profilinize bağlıdır:

BlogVault: Sürekli (incremental) yedekleme, tek tıkla geri yükleme ve staging ortamı sunar. Büyük WooCommerce mağazaları için tercih edilir.
Jetpack VaultPress Backup: Gerçek zamanlıya yakın yedekleme; özellikle her sipariş sonrası yedek isteyen e-ticaret siteleri için idealdir.
Solid Backups (eski adıyla BackupBuddy): Hem yedek hem migration aracı; ImportBuddy ile kolay taşıma sağlar.
Duplicator: Site klonlama ve göç için en iyi çözüm; yedek olarak da kullanılabilir.
WPvivid: UpdraftPlus’a hafif ve modern bir alternatif; staging ve migration özellikleri ücretsizdir.

Yöntem 2: Hosting Kontrol Paneli ile Yedek Alma

Pek çok hosting sağlayıcısı kontrol paneli üzerinden tam hesap yedeği indirmeyi destekler. Bu yedekler, dosyaların tar.gz arşivi ve veritabanlarının .sql dökümünü tek dosyada birleştirir.

cPanel ile Yedek

cPanel’e giriş yapın → “Files” bölümü → Backup Wizard.
“Back Up” → “Full Backup” → hedef olarak “Home Directory” seçin.
Yedek tamamlandığında backup-MM-DD-YYYY_username.tar.gz dosyasını indirebilirsiniz.
Yalnızca veritabanı için: “Backup Wizard” → “MySQL Databases” → ilgili veritabanını indirin.

JetBackup 5 (LiteSpeed/cPanel için)

Çoğu modern paylaşımlı hosting JetBackup eklentisi sunar. Adımlar:

cPanel → “JetBackup 5” simgesi.
“Full Account Backups” → “Generate Download” — istek kuyruğa alınır.
Hazır olduğunda “Download” tıklayıp .tar.gz dosyasını indirin.

Plesk ile Yedek

Plesk → Tools & Settings → Backup Manager.
“Back Up” → “All configuration and content” → “Type: Full”; planlama için “Schedule” sekmesinden cron ayarı yapın.
FTP, S3 veya Google Drive uzak depolaması ekleyin.

Hosting yedeklerini “yegane yedek” olarak görmeyin; hosting hesabı askıya alınırsa erişiminiz kesilir. Mutlaka kendi bilgisayarınıza ve bir bulut depolama hesabınıza da indirin.

Yöntem 3: Manuel Yedekleme (Pro Yöntem)

Tam kontrol isteyen, VPS ya da kendi sunucusunda WordPress çalıştıran site sahipleri için manuel yedek en güvenilir seçenektir.

SSH ile Dosya Yedeği

Sunucunuza SSH ile bağlanın ve aşağıdaki komutla wp-content dahil tüm WordPress dizininin sıkıştırılmış arşivini oluşturun:

# /var/www/html/example.com içinde çalıştırın
TS=$(date +%F-%H%M)
tar --warning=no-file-changed \
    --exclude="wp-content/cache" \
    --exclude="wp-content/uploads/wpvivid" \
    --exclude="wp-content/updraft" \
    -czf /backups/example-files-$TS.tar.gz .
ls -lh /backups/

--exclude bayrakları cache ve diğer eklentilerin geçici klasörlerini hariç tutar; bu, yedek boyutunu önemli ölçüde küçültür.

mysqldump ile Veritabanı Yedeği

MySQL/MariaDB veritabanı için mysqldump hâlâ standarttır:

# Veritabanı kimlik bilgilerini wp-config.php içinden okuyun
DB_NAME=$(grep DB_NAME /var/www/html/example.com/wp-config.php | cut -d \' -f 4)
DB_USER=$(grep DB_USER /var/www/html/example.com/wp-config.php | cut -d \' -f 4)
DB_PASS=$(grep DB_PASSWORD /var/www/html/example.com/wp-config.php | cut -d \' -f 4)

TS=$(date +%F-%H%M)
mysqldump --single-transaction --quick --lock-tables=false \
  --default-character-set=utf8mb4 \
  -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" \
  | gzip -9 > /backups/example-db-$TS.sql.gz

--single-transaction InnoDB tablolarında tablo kilidi olmadan tutarlı yedek alır; bu canlı bir sitenin yedeklenmesi sırasında kritik öneme sahiptir.

WP-CLI ile Tek Komut Yedek

WP-CLI yüklüyse veritabanı yedeği tek komuta indirgenir:

# WordPress kök dizininde
wp db export /backups/example-db-$(date +%F).sql --add-drop-table
gzip -9 /backups/example-db-*.sql

# Tüm site (dosyalar + db) için tek komut:
wp db export - | gzip -9 > /backups/db-$(date +%F).sql.gz \
  && tar -czf /backups/files-$(date +%F).tar.gz wp-content wp-config.php .htaccess

Cron ile Otomatikleştirme

Manuel komutları cron’a ekleyerek otomatikleştirin. crontab -e ile aşağıyı ekleyin:

# Her gün 03:15'te tam yedek; 14 günden eski yedekleri sil
15 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1
0  4 * * 0 find /backups -mtime +14 -delete

/usr/local/bin/wp-backup.sh dosyasına yukarıdaki tar ve mysqldump komutlarını koyun, chmod +x ile çalıştırılabilir yapın.

Yedekleri Güvenli Saklamak: Off-site Depolama

Yerel sunucudaki yedek, sunucu çökerse işe yaramaz. Off-site (uzak) saklama için en yaygın seçenekler:

Amazon S3 / S3-uyumlu Depolama

S3, S3-uyumlu Backblaze B2, Wasabi veya Cloudflare R2 hesabı oluşturduktan sonra aws-cli ile yedeği yüklemek tek satırlık bir iştir:

# aws-cli yapılandırması: aws configure
aws s3 cp /backups/example-files-$(date +%F-%H%M).tar.gz \
  s3://my-wp-backups/example.com/ --storage-class STANDARD_IA

Rclone ile Google Drive / Dropbox / OneDrive

Rclone, 50+ bulut depolama sağlayıcısını destekleyen açık kaynaklı bir araçtır:

# İlk kurulumda: rclone config (gdrive remote oluşturun)
rclone copy /backups/ gdrive:wp-backups/ --include "*.gz" \
  --progress --transfers 4 --checkers 8

Şifreleme

Yedeklerin uzak sunucuya gönderilmeden önce şifrelenmesi tavsiye edilir. Basit ve güvenli yöntem GPG’dir:

# Şifreleme
gpg --symmetric --cipher-algo AES256 example-db-2026-04-25.sql.gz

# Geri açma
gpg --decrypt example-db-2026-04-25.sql.gz.gpg > restored.sql.gz

Yedekten Geri Yükleme

Test edilmemiş yedek, yedek değildir. Her yedek alma stratejisi ayda en az bir kez geri yükleme testiyle doğrulanmalıdır.

UpdraftPlus ile Geri Yükleme

WordPress yöneticisi → Ayarlar → UpdraftPlus Yedekleri.
“Existing Backups” sekmesinde uygun yedek satırına gidin.
“Restore” → bileşenleri seçin (Plugins, Themes, Uploads, Others, Database) → “Next”.
Geri yükleme tamamlandığında “Return to UpdraftPlus configuration” → “Delete Old Folders”.

Manuel Geri Yükleme (Felaket Senaryosu)

Site tamamen erişilemiyor ve yönetici paneli açılmıyorsa manuel geri yükleme yapılır:

# 1) Yedek dosyalarını sunucuya yükleyin (scp, sftp ya da hosting dosya yöneticisi)
scp example-files-2026-04-25.tar.gz user@server:/tmp/
scp example-db-2026-04-25.sql.gz   user@server:/tmp/

# 2) Mevcut bozuk dosyaları yedekleyin (önemli — geri dönüş için)
mv /var/www/html/example.com /var/www/html/example.com.broken-$(date +%F)
mkdir -p /var/www/html/example.com
cd /var/www/html/example.com

# 3) Dosyaları geri açın
tar -xzf /tmp/example-files-2026-04-25.tar.gz

# 4) Veritabanını sıfırlayıp geri yükleyin
mysql -u root -p -e "DROP DATABASE wp_example; CREATE DATABASE wp_example \
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
gunzip < /tmp/example-db-2026-04-25.sql.gz | mysql -u root -p wp_example

# 5) Dosya izinlerini düzeltin
find /var/www/html/example.com -type d -exec chmod 755 {} \;
find /var/www/html/example.com -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html/example.com

Geri yükleme sonrası mutlaka siteurl ve home seçeneklerinin doğru olduğunu kontrol edin:

wp option get siteurl
wp option get home
# Yanlışsa:
wp option update siteurl https://example.com
wp option update home    https://example.com
wp cache flush
wp rewrite flush --hard

Search-Replace ile URL Değişikliği (Migration)

Yedeği farklı bir alan adına geri yüklediyseniz veritabanındaki eski URL’leri değiştirmeniz gerekir. Naif bir sed serileştirmeyi (serialized) bozar; yerine WP-CLI kullanın:

wp search-replace 'https://eski.com' 'https://yeni.com' \
  --skip-columns=guid --report-changed-only --all-tables

WordPress Yedekleme Sorun Giderme Checklist

Yedekleme zaman aşımı: php.ini‘de max_execution_time ve memory_limit değerlerini artırın (örn. 300, 512M). Paylaşımlı hostingte mümkün değilse yedeği gece çalıştırın ve eklentinin “split archive” özelliğini kullanın.
Yedek dosyası bozuk: İndirdiğiniz arşivi tar -tzf file.tar.gz > /dev/null ile doğrulayın. Hata verirse aktarımı tekrar yapın; FTP yerine SFTP kullanın.
Veritabanı dökümünde karakter bozulması: mysqldump ve mysql komutlarına mutlaka --default-character-set=utf8mb4 ekleyin.
Dosya izinleri: Geri yükleme sonrası izinler 755/644 ve sahiplik www-data:www-data olmalı; yanlış izin 403/500 hatası üretir.
“Maintenance mode” takılı kaldı: Geri yüklemenin yarım kaldığı durumlar için kök dizindeki .maintenance dosyasını silin.
Eklenti aktivasyonu sorunu: Bazı eklentiler etkinleştirme sırasında veritabanına seçenek yazar; yedekte bu seçenekler yoksa wp plugin deactivate --all && wp plugin activate --all komutunu çalıştırın.
Salts/keys uyumsuzluğu: wp-config.php içindeki AUTH_KEY vb. değerleri yeni sunucuya da aynen taşıyın; aksi halde tüm kullanıcılar oturumu kapatır.
Object cache: Redis veya Memcached kullanılıyorsa wp cache flush ile cache’i mutlaka temizleyin.

WordPress Yedekleme İçin En İyi Pratikler

Profesyonel bir yedekleme rutininin omurgası şu kurallardan oluşur:

Otomatikleştirin: Manuel yedek hatırlanan yedektir; otomatik yedek her gün alınan yedektir.
Test edin: Ayda bir kez staging ortamına geri yükleme yapın; çalışmayan yedek yedek değildir.
Saklama süresi belirleyin: Günlük yedekleri 14 gün, haftalık yedekleri 8 hafta, aylık yedekleri 12 ay saklayın.
Sürüm öncesi yedek: Her büyük WordPress, PHP veya tema/eklenti güncellemesi öncesinde manuel yedek alın.
Şifreleyin: Yedekleriniz müşteri kişisel verileri içeriyorsa GPG/AES-256 ile şifreleyin (KVKK ve GDPR uyumu).
Yedek logu: Her yedeğin tarihi, boyutu, hash’i ve geri yükleme testinin tarihini bir CSV ya da Notion sayfasında kayıt altında tutun.
İzin gözden geçirme: Yedek dosyalarına erişimi olan kullanıcı sayısını minimumda tutun; wp-content/updraft ve /backups klasörlerine web erişimini engelleyin.

/backups dizinini web erişiminden kapatmak için Apache’de:

# /backups/.htaccess
Require all denied

Nginx için sunucu blokunda:

location ^~ /backups/ {
    deny all;
    return 403;
}

Sıkça Sorulan Sorular (SSS)

WordPress yedeklemesini ne sıklıkla almalıyım?

Aktif bir blog için günlük, e-ticaret sitesi için her saat ya da gerçek zamanlıya yakın, statik bir kurumsal site için haftalık yedek yeterlidir. WooCommerce gibi sürekli sipariş alan siteler için Jetpack VaultPress veya BlogVault’ın gerçek zamanlı yedek seçeneği değerlendirilmelidir.

Hosting sağlayıcımın yedeği yeterli değil mi?

Hayır. Hosting yedeği iyi bir ek katmandır ama tek başına yetersizdir. Hesabınız askıya alınır ya da hosting iflas ederse o yedeklere erişemezsiniz. 3-2-1 kuralı gereği en az bir kopyanın hosting dışında olması zorunludur.

Sadece veritabanını yedeklemem yeterli mi?

Hayır. Veritabanı yazılarınızı tutar ama medya, eklenti ve tema dosyalarını içermez. Sadece veritabanı yedeğiyle bir siteyi geri yükleyemezsiniz; mutlaka wp-content klasörü de yedeklenmelidir.

Otomatik yedek eklentisi sitemi yavaşlatır mı?

Yedek alma sırasında PHP işlemleri kısa süreli CPU kullanımı yapar. Etki minimize etmek için yedeği gece düşük trafikli saatlerde (örn. 03:00–04:00) zamanlayın ve “split archive” özelliğini açın. Büyük sitelerde sunucu tarafı (mysqldump + tar) çözümleri eklenti tabanlı çözümlerden çok daha az yük yaratır.

Yedeği nasıl test ederim?

En sağlam yöntem bir staging alt alanı oluşturup yedeği oraya geri yüklemektir. Pek çok hosting tek tıkla staging sunar; UpdraftPlus Premium ve BlogVault da aynı özelliği eklenti içinde sağlar. Geri yükleme bittiğinde anasayfa, giriş ekranı, ödeme akışı ve API uçlarını manuel kontrol edin.

WordPress.org’un yedek önerisi nedir?

WordPress dokümantasyonu, “Backup of WordPress files and database is essential before any major update” der. Yani büyük WordPress sürüm güncellemesi (örn. 6.x → 6.y), PHP sürüm yükseltmesi ve veritabanı şema değişikliği öncesi yedek almanız resmi tavsiyedir.

WP-CLI olmadan da manuel yedek alabilir miyim?

Evet. mysqldump ve tar her Linux sunucuda kuruludur; bu iki komut ile WP-CLI olmadan tam yedek alınabilir. WP-CLI sadece komutları kısaltır ve serileştirilmiş veriyi güvenle değiştiren search-replace gibi yardımcılar sunar.

Yedeklerimi ne kadar süre saklamalıyım?

3-2-1 kuralının pratik uygulaması olarak şu rotasyonu öneriyoruz: günlükler 14 gün, haftalıklar 8 hafta, aylıklar 12 ay. KVKK/GDPR’a tabi siteler 6 yıllık yasal saklama süresi gerektirebilir; bu durumda aylık arşivler şifrelenmiş olarak soğuk depolamaya (Glacier, B2 Archive) gönderilmelidir.

Site taşıma (migration) sırasında yedek nasıl kullanılır?

Eski sunucudan tam yedek (dosya + db) alın → yeni sunucuya yükleyin → veritabanını yeni sunucuda oluşturup içe aktarın → wp-config.php içinde DB bilgilerini güncelleyin → wp search-replace ile URL değiştirin → DNS’i yeni sunucuya yönlendirin. Duplicator ve Solid Backups gibi eklentiler bu adımları tek bir kurulum sihirbazına paketler.

Kaynak Önerileri

Konunun derinine inmek isteyen site sahipleri için faydalı kaynaklar:

WordPress.org — WordPress Backups (resmi dokümantasyon)
WP-CLI — wp db export referansı
UpdraftPlus SSS
Rclone Dokümantasyonu
WPNeta — Hack Sonrası 7 Adım
WPNeta — WordPress İçin En Uygun Hosting Seçimi
WPNeta — WordPress Beyaz Ekran Hatası
WPNeta — Veritabanı Bağlantı Hatası Rehberi

Sonuç

WordPress yedekleme bir defaya mahsus yapılan bir iş değil, sürdürülebilir bir disiplindir. Site sahibi olarak amacınız “yedeğim var mı?” sorusuna her zaman evet cevabını verebilmektir. UpdraftPlus gibi bir eklentiyle 30 dakika içinde otomatik bir yedek rutini kurabilir, hosting panelinizden tam hesap yedeğini bilgisayarınıza indirebilir ve VPS/sunucu kullanıyorsanız mysqldump + tar + cron üçlüsüyle profesyonel düzeyde bir yedekleme sistemine sahip olabilirsiniz. 3-2-1 kuralına bağlı kalın, her ay bir kez geri yükleme testi yapın ve yedeklerinizi şifreleyerek off-site saklayın. Böylece bir gün gerçekten gerektiğinde — ki gerekecektir — saatler değil, dakikalar içinde sitenizi ayağa kaldırabilirsiniz.