Site Yedeği Nasıl Alınır? Dosya ve Veritabanı Yedekleme Rehberi

Site yedeği nasıl alınır sorusunu soranların çoğu, aslında bunu daha önce bir kez yaptığını sanıyor. cPanel'e girip "Tam Yedekleme" düğmesine basmış, bir e-posta gelmiş, tamam demiş. Sonra bir gün site bozuluyor, o yedeği indirip açıyor ve içinde aradığı şeyin — çoğu zaman veritabanının güncel hâlinin ya da e-posta kutularının — olmadığını fark ediyor. Bu yazının varlık sebebi tam olarak bu: bir web sitesinin yedeği tek bir dosya değildir, en az dört ayrı parçadan oluşur ve o parçaların hepsinin aynı yedekte olduğunu varsaymak en pahalı hatadır.

Aşağıda web sitesi yedekleme işini parça parça anlatacağım. Önce bir sitenin tam yedeğinin hangi bileşenlerden oluştuğunu netleştireceğiz. Sonra cPanel'in tam yedekleme aracının tam olarak neyi alıp neyi almadığını, indirdiğiniz .tar.gz arşivinin içinde ne olduğunu klasör klasör göstereceğim. Ardından aynı işi FTP ve SSH ile nasıl yapacağınızı, veritabanını neden ayrı düşünmek zorunda olduğunuzu ve en önemlisi aldığınız yedeğin gerçekten işe yarayıp yaramadığını nasıl doğrulayacağınızı anlatacağım. Yıllardır gördüğüm en yaygın felaket, "yedeğim var" diyen birinin geri yüklerken yedeğin bozuk ya da eksik olduğunu keşfetmesidir.

Bir Sitenin Tam Yedeği Hangi Parçalardan Oluşur#

Bir web sitesinin tam yedeği dört ayrı bileşenden oluşur ve bunların yalnızca ilk ikisi çoğu "yedek al" düğmesinin kapsamındadır.

Dördüncü satır en çok küçümsenendir. Dosyaları ve veritabanını sorunsuz geri yüklediğiniz hâlde site çalışmıyorsa, sebep genellikle eksik bir veritabanı kullanıcısı, çalışmayan bir cron görevi ya da eski sunucuda kalmış bir .htaccess kuralıdır.

WordPress özelinde durumu somutlaştıralım. WordPress'in içeriği tamamen veritabanındadır: her yazı, her sayfa, her yorum, her ayar. wp-content/uploads klasöründeki dosyalar ise yalnızca görsellerdir. Yani sadece dosyaları yedeklerseniz elinizde görselli ama yazısız bir site kalır; sadece veritabanını yedeklerseniz yazılı ama görselsiz bir site. İkisi olmadan geri dönüş yoktur.

cPanel Tam Yedekleme Aracı Gerçekte Neyi Alır#

cPanel'in "Tam Yedekleme" aracı dosyaları, veritabanlarını, e-posta hesaplarını ve hesap yapılandırmasını tek arşivde toplar — ama bu arşivi doğrudan tarayıcıdan indiremezsiniz.

Adımlar şöyle:

1. cPanel'e giriş yapın.
2. Dosyalar bölümünden Yedekleme (Backup) aracını açın.
3. Tam Hesap Yedeği İndir (Download a Full Account Backup) bağlantısına tıklayın.
4. Hedef dizin olarak Ana Dizin (Home Directory) seçin.
5. İsterseniz bir e-posta adresi girin; işlem bitince bildirim gelir.
6. Yedek Oluştur düğmesine basın.

Buradaki en kritik ayrıntı şudur: bu araç size anında bir dosya vermez. Sunucu arka planda arşivi hazırlar ve hesabınızın ana dizinine koyar. Sitenizin boyutuna göre bu işlem birkaç dakika ile birkaç saat arasında sürebilir. İşlem bittiğinde arşivi Dosya Yöneticisi'nden veya FTP ile indirmeniz gerekir.

⚠️ Arşiv hesabınızın kendi disk alanında oluşur. Yani 8 GB'lık bir siteniz varsa ve disk kotanız 10 GB ise, yedek oluşturulurken kotayı aşarsınız ve işlem yarıda kalır. Sitesi büyük olan kullanıcılarda "yedek bir türlü tamamlanmıyor" şikâyetinin nedeni neredeyse her zaman budur. Bu durumda tam yedek yerine parçalı yedek almanız gerekir.

Aynı ekranda bir de Kısmi Yedekler bölümü vardır ve bunlar doğrudan indirilir:

• Ana Dizin — sadece dosyalar.
• MySQL Veritabanları — her veritabanı için ayrı bir .sql.gz bağlantısı.
• E-posta İletme Yapılandırması ve E-posta Filtreleri.

Küçük ve orta ölçekli sitelerde kısmi yedekler tam yedekten daha pratiktir; hem kota sorunu yaratmaz hem de hangi parçayı aldığınızı net görürsünüz. cPanel yedekleme ekranının tüm seçeneklerini ayrıntılı incelemek isterseniz cPanel yedekleme yazısına bakabilirsiniz.

İndirdiğiniz Arşivin İçinde Tam Olarak Ne Var#

Tam yedek arşivini açtığınızda karşınıza çıkan yapı, cPanel hesabınızın birebir kopyasıdır ve her klasör ayrı bir amaca hizmet eder.

Arşivi Linux veya macOS'ta şöyle açarsınız:

tar -xzvf backup-8.11.2026_00-00-00_kullanici.tar.gz

Windows'ta 7-Zip gibi bir araçla iki aşamada (önce .gz, sonra .tar) açmanız gerekir.

İçindeki yapı kabaca şudur:

backup-8.11.2026_00-00-00_kullanici/
├── homedir/                  → hesabın tüm dosyaları
│   ├── public_html/          → sitenin kök dizini
│   ├── mail/                 → e-posta kutuları (Maildir yapısı)
│   ├── etc/                  → e-posta hesapları ve şifre karmaları
│   ├── logs/                 → erişim ve hata kayıtları
│   └── ssl/                  → sertifika dosyaları
├── mysql/                    → her veritabanı için ayrı .sql dosyası
│   ├── kullanici_wp.sql
│   └── kullanici_wp.create
├── mysql.sql                 → veritabanı kullanıcıları ve yetkileri
├── cron/                     → zamanlanmış görevler
├── dnszones/                 → alan adının DNS bölge dosyası
├── va/                       → sanal sunucu (vhost) ayarları
└── meta/                     → hesap meta bilgileri

Bu ağacı bir kez gördüğünüzde "yedeğim var mı" sorusu somutlaşır. Elinizdeki dosya bu yapıya sahipse gerçekten tam yedeğiniz var demektir. Elinizde sadece public_html klasörünün bir zip'i varsa, veritabanınız yok demektir ve o yedekle WordPress sitesini ayağa kaldıramazsınız.

mysql/ klasörüne özellikle bakın. İçinde sitenizin kullandığı veritabanının .sql dosyası var mı ve boyutu makul mü? Birkaç kilobayt boyutunda bir .sql dosyası, veritabanının boş alındığına işaret eder — bu, sessizce oluşan ve geri yükleme anına kadar fark edilmeyen bir hatadır.

dnszones/ klasörü de değerlidir. Alan adınızın tüm DNS kayıtları burada metin dosyası olarak durur; başka bir sunucuya geçerken kayıtları elle yeniden yazmak yerine bu dosyayı referans alırsınız.

Sadece Dosyaları Yedekleme: FTP ve Dosya Yöneticisi#

Yalnızca dosyaları yedeklemek istiyorsanız en pratik yöntem, sunucuda sıkıştırıp tek dosya olarak indirmektir; klasörü doğrudan FTP ile çekmek çok daha yavaştır.

Dosya Yöneticisi ile (önerilen):

1. cPanel → Dosya Yöneticisi'ni açın.
2. Sol panelden public_html klasörünü seçin (üstüne tıklayın, içine girmeyin).
3. Üst menüden Sıkıştır (Compress) düğmesine basın.
4. Arşiv türü olarak Tar Gzip seçin, isim verin ve onaylayın.
5. Oluşan .tar.gz dosyasını seçip İndir düğmesine basın.

Bu yöntem binlerce küçük dosyayı tek bir dosyaya indirger. Bir WordPress kurulumunda ortalama on binin üzerinde dosya bulunur; bunları FTP ile tek tek çekmek saatler sürer ve bağlantı koparsa nerede kaldığınızı bilemezsiniz. Sıkıştırılmış tek dosyada bu risk yoktur. Dosya Yöneticisi'nin diğer yetenekleri için cPanel dosya yöneticisi yazısına göz atabilirsiniz.

FTP/SFTP ile: Yine de dosyaları doğrudan çekmek isterseniz FileZilla gibi bir istemciyle bağlanıp public_html klasörünü yerel bir klasöre sürükleyin. Aktarım bittiğinde dosya sayısını mutlaka karşılaştırın; FTP aktarımları büyük klasörlerde sessizce yarıda kesilir ve eksik yedek, olmayan yedekten daha tehlikelidir çünkü size güven verir.

Gizli dosyaları atlamayın. .htaccess başta olmak üzere nokta ile başlayan dosyalar FTP istemcilerinde varsayılan olarak görünmez. FileZilla'da Sunucu → Gizli dosyaları göstermeye zorla seçeneğini açın. .htaccess içindeki yönlendirme ve güvenlik kuralları kaybolursa site geri yüklendiğinde bağlantılar kırılır.

Hangi klasörlerin mutlaka yedeğe girmesi gerektiği konusunda kısa bir liste:

Buna karşılık wp-content/cache/, wp-content/upgrade/ ve benzeri geçici klasörleri yedeğe dahil etmeniz gerekmez; boyutu şişirir, işe yaramazlar.

Veritabanını Ayrı Yedekleme: phpMyAdmin ve mysqldump#

Veritabanı, dosyalardan tamamen ayrı bir yerde durur ve bir dosya yedeği aldığınızda kesinlikle dahil edilmez — bu ayrımı kavramak yedeklemenin en kritik noktasıdır.

Önce hangi veritabanını yedekleyeceğinizi bulmanız gerekir. WordPress'te bu bilgi wp-config.php dosyasındadır:

define( 'DB_NAME', 'kullanici_wp' );
define( 'DB_USER', 'kullanici_wpuser' );
define( 'DB_HOST', 'localhost' );

DB_NAME değeri yedekleyeceğiniz veritabanının adıdır.

phpMyAdmin ile:

1. cPanel → phpMyAdmin'i açın.
2. Sol listeden veritabanınızı seçin.
3. Üst sekmelerden Dışa Aktar (Export) sekmesine geçin.
4. Yöntem olarak Özel (Custom) seçin — hızlı yöntemi değil.
5. Tabloların tamamının seçili olduğunu doğrulayın.
6. Çıktı bölümünde gzip ile sıkıştır seçeneğini işaretleyin.
7. Biçim SQL kalsın ve Dışa Aktar düğmesine basın.

"Özel" seçeneğini önermemin nedeni, hızlı yöntemin bazı sunucularda büyük tabloları sessizce kesmesidir. Özel modda tablo listesini gözünüzle doğrulayabilir, eksik seçili bir tablo varsa fark edebilirsiniz.

phpMyAdmin, tarayıcı üzerinden çalıştığı için büyük veritabanlarında zaman aşımına uğrayabilir. 100 MB'ı geçen veritabanlarında SSH yöntemi çok daha güvenilirdir.

SSH ve mysqldump ile:

mysqldump -u kullanici_wpuser -p --single-transaction --quick kullanici_wp > yedek.sql
gzip yedek.sql

Parametrelerin anlamı önemlidir:

• --single-transaction — InnoDB tablolarında tutarlı bir anlık görüntü alır ve tabloları kilitlemez; canlı sitede bunu atlamayın.
• --quick — büyük tabloları satır satır okuyup belleği şişirmez.

Sonuç dosyasının boş olmadığını hemen kontrol edin:

ls -lh yedek.sql.gz
zcat yedek.sql.gz | head -20

İlk satırlarda -- MySQL dump başlığını ve CREATE TABLE ifadelerini görmelisiniz. Görmüyorsanız döküm başarısız olmuştur. Komutun tüm seçenekleri ve otomatikleştirme yöntemleri için mysqldump ile veritabanı yedekleme yazısı ayrıntılı.

SSH ile Tek Komutta Tam Yedek#

SSH erişiminiz varsa, sitenin dosyalarını ve veritabanını tek oturumda tarihli bir arşive almak birkaç satırla mümkündür.

#!/bin/bash
TARIH=$(date +%F)
HEDEF=~/yedekler
mkdir -p "$HEDEF"

# Veritabanı dökümü
mysqldump -u kullanici_wpuser -p'PAROLA' --single-transaction --quick kullanici_wp \
  | gzip > "$HEDEF/db-$TARIH.sql.gz"

# Dosyalar
tar -czf "$HEDEF/dosyalar-$TARIH.tar.gz" \
  --exclude='wp-content/cache' \
  --exclude='wp-content/upgrade' \
  -C ~/ public_html

ls -lh "$HEDEF"

Bu betiği ~/yedek-al.sh olarak kaydedip çalıştırma izni verin:

chmod 700 ~/yedek-al.sh

Parolayı komut satırına yazmak ideal değildir; daha temiz yol, ana dizininizde .my.cnf dosyası oluşturmaktır:

[client]
user=kullanici_wpuser
password=PAROLANIZ

chmod 600 ~/.my.cnf

Bu dosya varken mysqldump komutuna parola yazmanız gerekmez.

Betiği zamanlanmış görev olarak çalıştırmak isterseniz cPanel → Cron İşleri ekranından günlük bir kayıt ekleyebilirsiniz:

0 3 * * * /bin/bash /home/kullanici/yedek-al.sh > /home/kullanici/yedek.log 2>&1

⚠️ Bu betik yedeği aynı sunucuda oluşturur. Sunucu diski bozulursa veya hesap askıya alınırsa yedeğiniz de gider. Bu yüzden bir sonraki adım, yedeği başka bir yere kopyalamaktır.

E-posta Hesapları, Cron Görevleri ve DNS Kayıtları#

Site dosyaları ve veritabanı dışında kalan üç bileşen — e-posta, zamanlanmış görevler ve DNS — çoğu yedekleme rehberinde hiç geçmez ama geri yükleme sırasında en çok sorun çıkaran kısımdır.

E-posta kutuları cPanel hesabınızın mail/ klasöründe, Maildir yapısında tutulur. Her hesap için ayrı bir klasör, her ileti için ayrı bir dosya vardır. Tam hesap yedeğinde bu klasör dahildir, ancak public_html klasörünü sıkıştırdığınızda dahil değildir — çünkü mail/ klasörü public_html içinde değil, onun kardeşidir. Sadece e-postaları yedeklemek isterseniz Dosya Yöneticisi'nde ana dizine çıkıp mail klasörünü ayrıca sıkıştırın.

E-posta hesaplarının kendisi (adresler ve şifre karmaları) ise etc/ klasöründedir. Bu klasör olmadan, mail/ içindeki iletileri geri yüklerseniz kutular vardır ama hesaplar tanımlı değildir.

Cron görevleri veritabanında değil, sunucunun kendi zamanlayıcısındadır. Mevcut görevlerinizi listelemek için:

crontab -l

Çıktıyı bir dosyaya kaydedin:

crontab -l > ~/yedekler/cron-$(date +%F).txt

Bunu atlarsanız, geri yükleme sonrası sitenin yedekleme, e-posta gönderimi ve senkronizasyon gibi arka plan işleri sessizce çalışmaz. Sorun fark edilene kadar günler geçebilir.

DNS kayıtları ise hosting hesabınızın değil, alan adınızın yönetildiği panelin verisidir. Tam hesap yedeğindeki dnszones/ klasörü bir kopya tutar ama bu kopya, alan adınızın nameserver'ları başka bir yerdeyse geçerli olmayabilir. Kritik kayıtlarınızı (A, MX, TXT/SPF, CNAME) elle bir metin dosyasına da yazın. Özellikle MX ve SPF kayıtlarını kaybetmek e-posta akışını durdurur ve fark edilmesi günler alır.

Yedeği Nereye Saklamalı ve Ne Sıklıkta Almalı#

Yedeğin sunucuda durması yedek sayılmaz; gerçek yedek, en az bir kopyası sunucunun dışında duran yedektir.

Uygulanabilir bir düzen şudur:

Sıklığı belirlerken sorulacak tek soru şudur: kaç saatlik veri kaybını göze alabilirsiniz? Haftada iki yazı yayımlayan bir blog için haftalık yedek yeterlidir. Günde elli sipariş alan bir mağazada günlük yedek bile fazla seyrektir; orada saatlik veritabanı dökümü mantıklıdır. Bu kararın ayrıntılı çerçevesi için ne sıklıkta yedek alınmalı yazısına bakabilirsiniz.

Bir de sık karşılaşılan bir yanılgı var: "hosting firmam zaten yedek alıyor". Sağlayıcı yedeği sunucu düzeyinde bir felakete karşı alınır; sizin kendi hatanızı (yanlış eklenti güncellemesi, silinen sayfa, hacklenen site) belirli bir tarihe geri almak için tasarlanmamış olabilir ve saklama süresi sınırlıdır. İki yedeğin farkını hosting yedeği mi kendi yedeğim mi yazısı karşılaştırıyor. Kısa cevap: sağlayıcı yedeği bir ek güvencedir, kendi yedeğinizin yerini tutmaz.

Aldığınız Yedeğin Çalıştığını Doğrulama#

Test edilmemiş yedek, yedek değildir — ve bunu geri yükleme gününde öğrenmek en kötü senaryodur.

Doğrulamanın hızlı hâli şu üç kontroldür:

1. Boyut kontrolü. Arşiv birkaç kilobayt mı? O hâlde boştur. Sitenizin gerçek boyutuyla makul ölçüde orantılı olmalıdır.
2. Arşiv bütünlüğü. Dosya yarıda kesilmişse açılmaz:

gzip -t yedek.sql.gz && echo "arşiv saglam"
tar -tzf dosyalar.tar.gz > /dev/null && echo "arsiv saglam"

3. İçerik kontrolü. SQL dosyasının içinde beklediğiniz tablolar var mı:

zcat yedek.sql.gz | grep -c "CREATE TABLE"

Bir WordPress kurulumunda bu sayı en az on iki olmalıdır (temel tablolar) ve eklentilerle birlikte çok daha yükseğe çıkar. Sonuç sıfır veya bire iki ise dökümünüz eksiktir.

Gerçek doğrulama ise geri yükleme provasıdır. Yılda en az bir kez yedeğinizi ayrı bir alt alan adına veya yerel bir test ortamına kurun, siteyi açın, birkaç sayfayı gezin, yönetim paneline girin. Bu prova bir saatinizi alır ve karşılığında yedeğinizin gerçekten çalıştığını bilirsiniz. Provada en sık çıkan iki sorun, veritabanı kullanıcısının yetkilendirilmemiş olması ve dosya izinlerinin yanlış aktarılmasıdır; ikisini de gerçek bir felaket anında değil, provada öğrenmek istersiniz.

Bir de dosya adlandırma disiplini edinin. yedek.zip, yedek-son.zip, yedek-son2.zip gibi isimler birkaç ay sonra hangisinin ne olduğunu anlamanızı imkânsız kılar. site-adi-2026-08-11-dosyalar.tar.gz biçiminde tarihli ve içerik belirten bir isim kullanın.

Sıkça Sorulan Sorular#

Site yedeği almak siteyi yavaşlatır mı#

Yedek alma işlemi sunucu kaynaklarını geçici olarak kullanır ve büyük sitelerde site kısa süreliğine yavaşlayabilir. Tam hesap yedeği, tüm dosyaları okuyup sıkıştırdığı için disk ve işlemci yükü oluşturur; paylaşımlı hostingte bu etki daha belirgindir. Bu yüzden yedekleme işini trafiğin en düşük olduğu saatlere zamanlayın, genellikle gece yarısı ile sabahın erken saatleri arasına. Veritabanı dökümünü --single-transaction parametresiyle almak da tabloları kilitlemediği için siteyi ayakta tutar.

Sadece dosyaları yedeklemem yeterli mi#

Hayır, yeterli değildir; WordPress, WooCommerce, OpenCart gibi tüm dinamik sistemlerde içeriğin tamamı veritabanında durur. Sadece dosya yedeğiyle geri dönerseniz tema, eklenti ve görselleriniz gelir ama yazılar, sayfalar, kullanıcılar, ayarlar ve siparişler gelmez. Statik bir HTML sitesi kullanıyorsanız dosya yedeği tek başına yeterlidir, çünkü veritabanı yoktur. Emin değilseniz sitenizin bir yönetim paneli olup olmadığına bakın; varsa mutlaka veritabanı da vardır.

Yedek dosyasını nereye saklamalıyım#

En az bir kopyayı hosting hesabınızın dışında saklamalısınız. Sunucuda tutulan yedek yalnızca hızlı geri dönüş içindir; disk arızası, hesabın askıya alınması veya sunucu düzeyinde bir sorun durumunda yedeğiniz de erişilemez hâle gelir. Pratik düzen, bir kopyayı sunucuda, bir kopyayı kendi bilgisayarınızda veya harici diskte, bir kopyayı da farklı bir konumdaki uzak depolamada tutmaktır. Üç kopyanın aynı anda kaybolma ihtimali pratikte sıfıra yakındır.

cPanel tam yedeği neden indirilemiyor#

Tam hesap yedeği tarayıcıya doğrudan indirilmez; sunucu arşivi arka planda hazırlayıp hesabınızın ana dizinine koyar. İşlem bittiğinde Dosya Yöneticisi'nden veya FTP ile indirmeniz gerekir. Arşiv hiç oluşmuyorsa en yaygın neden disk kotasının yetmemesidir, çünkü arşiv sizin kendi alanınızda oluşturulur ve sitenizin boyutu kadar ek yer ister. Bu durumda tam yedek yerine ana dizin ve veritabanı yedeklerini ayrı ayrı almak çözümdür.

Yedekten geri yükledim ama site açılmıyor, neden#

Bu genellikle veritabanı bağlantı bilgilerinin yeni ortamla uyuşmamasından kaynaklanır. Veritabanını geri yüklediğinizde veritabanı adı, kullanıcı adı veya parola değişmiş olabilir; yapılandırma dosyasındaki bilgilerle eşleşmezse site bağlantı hatası verir. İkinci sık neden, veritabanı kullanıcısının veritabanı üzerinde yetkilendirilmemiş olmasıdır — kullanıcı ve veritabanı ayrı ayrı oluşturulur, sonra birbirine bağlanır. Üçüncü olarak dosya izinlerini kontrol edin; yanlış izinler sunucunun dosyaları okumasını engeller.

E-posta hesaplarım yedeğe dahil mi#

Tam hesap yedeğinde dahildir, ancak yalnızca site klasörünü sıkıştırdığınızda dahil değildir. E-posta iletileri hesabınızın mail klasöründe, hesap tanımları ise etc klasöründe durur ve bu iki klasör site kök dizininin içinde değil, onunla aynı seviyededir. Sadece e-postaları yedeklemek isterseniz ana dizine çıkıp bu iki klasörü ayrıca arşivlemeniz gerekir. Posta istemcisi kullanıyorsanız iletilerin bir kopyası zaten bilgisayarınızda olabilir, ancak IMAP kullanıyorsanız iletiler sunucuda durur ve yedeklenmesi gerekir.

Yedekleme eklentisi kullanmak yeterli mi#

Yedekleme eklentileri pratik bir çözümdür ancak tek başına bırakılmamalıdır. Eklentiler site içinden çalıştığı için, sitenin kendisi bozulduğunda veya yönetim paneline girilemediğinde yedek almak ya da geri yüklemek mümkün olmayabilir. Ayrıca eklentiler e-posta kutularını, cron görevlerini ve sunucu düzeyindeki yapılandırmayı kapsamaz. Eklenti ile alınan otomatik yedeklerin yanında, dönemsel olarak sunucu tarafından tam hesap yedeği de almanız daha güvenli bir düzen kurar.

Yedek dosyalarını ne kadar süre saklamalıyım#

En az bir aylık geriye dönük yedek tutmanız önerilir, çünkü bazı sorunlar hemen fark edilmez. Sitenize zararlı yazılım bulaştığında veya bir içerik yanlışlıkla silindiğinde bunu günler sonra fark edebilirsiniz; elinizde yalnızca son yedek varsa o yedek de zaten bozulmuş hâli içerir. Pratik bir düzen, son yedi günün günlük yedeğini, son dört haftanın haftalık yedeğini ve son birkaç ayın aylık yedeğini tutmaktır. Böylece hem yakın geçmişe ince ayrıntıyla hem de uzak geçmişe kabaca dönebilirsiniz.

Kapanış#

Site yedeği almak tek bir düğmeye basmak değil, dört ayrı bileşeni — dosyalar, veritabanı, e-posta ve yapılandırma — bilinçli olarak kapsamaya almaktır. cPanel'in tam yedekleme aracı bu dördünü de içerir ama kota nedeniyle her zaman tamamlanmaz; kısmi yedekler daha kontrollüdür, SSH yöntemi ise en esneğidir. Hangi yolu seçerseniz seçin, üç şeyi asla atlamayın: yedeğin en az bir kopyasını sunucunun dışında tutun, dosyaları tarihli ve anlaşılır adlarla saklayın ve yılda en az bir kez gerçek bir geri yükleme provası yapın. Test edilmemiş bir yedek, ancak ihtiyaç duyduğunuz gün işe yaramadığını öğreneceğiniz bir dosyadır.

Bu işi elle yürütmek istemiyorsanız yedekleme hizmetimiz dosya ve veritabanı kopyalarını planlı biçimde sunucu dışına alır ve geri yükleme sürecini üstlenir. Yedekleme sırasında disk kotanızın yetmediğini fark ettiyseniz, daha geniş alan sunan hosting paketlerine geçmek veya kaynakları size ayrılmış bir VDS sunucuya taşınmak kalıcı çözümdür; VDS tarafında anlık görüntü alma ve kendi zamanlanmış yedek betiğinizi çalıştırma esnekliği de kazanırsınız.