Site Yedekleme Rehberi: Neyi, Nereye, Ne Sıklıkla Yedeklemeli
Yedek almadığını fark eden insanların çoğu bunu bir eklenti güncellemesinden ya da bir saldırıdan sonra fark eder. O anda sorulan ilk soru hep aynıdır: "Hosting firması yedek alıyordur değil mi?" Genelde alıyordur, ama o yedek sizin yedeğiniz değildir ve her senaryoda işinize yaramaz.
İyi bir yedekleme planı üç sorunun cevabıdır: neyi yedekliyorum, kaç kopya nerede duruyor, ve bu yedekten gerçekten geri dönebiliyor muyum. Üçüncüsü en çok atlanan ve en pahalıya patlayan sorudur.
Bir sitenin üç ayrı parçası vardır
"Siteyi yedekledim" cümlesi çoğu zaman eksiktir, çünkü site tek parça değildir.
- Dosyalar:
public_htmliçindeki her şey. Tema, eklenti, yüklenen görseller (wp-content/uploads),.htaccessvewp-config.php. Bunlar olmadan tasarımınız yok. - Veritabanı: Yazılar, sayfalar, ürünler, siparişler, kullanıcılar, ayarlar. Bunlar olmadan içeriğiniz yok. phpMyAdmin ile SQL yedeği almayı ayrı bir yazıda adım adım anlattık.
- E-postalar: Sunucuda IMAP ile duran kutular. Şirket yazışmalarının çoğu buradadır ve bir hesap silindiğinde site yedeği bunu geri getirmez. E-posta yedekleme ayrı bir başlıktır.
Bunlara bir de dördüncü, sık unutulan kalem eklenir: DNS ve alan adı yapılandırması. Nameserver ayarlarınızın, MX kayıtlarınızın, TXT/SPF satırlarınızın bir ekran görüntüsü ya da metin dökümü, taşınma ya da kaza durumunda saatler kazandırır.
3-2-1 kuralı
Kurumsal dünyada kullanılan ve küçük bir site için de fazlasıyla geçerli olan kural şudur: 3 kopya, 2 farklı ortam, 1 tanesi başka bir fiziksel konumda.
| Kopya | Nerede | Rolü |
|---|---|---|
| 1 | Canlı sunucu | Asıl veri |
| 2 | Sağlayıcının yedek alanı / uzak sunucu | Hızlı geri dönüş |
| 3 | Kendi diskiniz veya bulut deposu | Sağlayıcıdan bağımsız güvence |
Üçüncü kopya kritiktir. Hosting hesabınız ödeme sorunu yüzünden askıya alınırsa, sağlayıcıyla bir anlaşmazlık yaşarsanız veya veri merkezinde donanım kaybı olursa elinizde sadece o kalır. Bir haftalık bir yedeği dizüstü bilgisayarınızda tutmak bile hiç tutmamaktan kat kat iyidir.
Sunucu yedeği ile kendi yedeğinizin farkı
Hosting sağlayıcıları genelde günlük ya da haftalık sunucu düzeyinde yedek tutar. Bu yedekler donanım arızası, disk bozulması gibi sağlayıcı kaynaklı sorunlar için tasarlanmıştır. Sizin hatanız için tasarlanmamıştır.
Farkları şöyle düşünün:
- Saklama süresi: Sunucu yedeği çoğunlukla son 7-14 günü tutar. Üç hafta önce bozulan ama bugün fark edilen bir şey için orada bir şey kalmamış olabilir.
- Kapsam: Sunucu yedeği tüm hesabı geri getirir. Sadece tek bir dosyayı ya da tek bir tabloyu geri almak isterseniz süreç zahmetlidir.
- Zamanlama: Yedek gece 03:00’te alınıyorsa, gün içinde girdiğiniz 40 siparişi kaybedersiniz. E-ticarette bu kabul edilemez.
- Erişim: Kendi yedeğinize istediğiniz an ulaşırsınız; sağlayıcı yedeği için talep açıp sıra beklersiniz.
Doğru yaklaşım ikisini birleştirmektir: sağlayıcının yedeği ağ güvenliğidir, sizinki ise asıl plandır. Hosting paketinizin yedekleme politikasını satın alırken sorun; "yedek var" cevabı yetmez, saklama süresini ve geri yükleme yöntemini öğrenin.
cPanel’den tam yedek indirmek
cPanel’de Dosyalar > Yedekleme ekranında iki seçenek vardır.
- Tam Hesap Yedeği: Dosyalar, veritabanları, e-posta hesapları, filtreler ve DNS bölgesi tek bir
.tar.gzarşivinde toplanır. Hazırlanması birkaç dakika sürer, bittiğinde bilgilendirme e-postası gelir. Bu arşiv doğrudan geri yüklenemez, sağlayıcıya iletmeniz gerekir; ama içindeki dosyaları elle çıkarabilirsiniz. - Kısmi yedek: Yalnızca ana dizin veya yalnızca seçtiğiniz bir veritabanı. Günlük düzenli iş için pratik olanı budur.
Disk alanınız doluysa yedek oluşturmayın; arşiv sunucuda yer kapladığı için hesabın limiti aşmasına ve sitenin durmasına yol açabilir. Önce yer açın, yedeği alın, indirdikten sonra sunucudaki kopyayı silin.
Ne sıklıkla yedek almalı?
Sıklığı belirleyen soru şu: "Kaç saatlik veriyi kaybetmeyi göze alabilirim?"
| Site türü | Dosya yedeği | Veritabanı yedeği |
|---|---|---|
| Kurumsal tanıtım sitesi | Ayda 1 veya değişiklikten sonra | Haftada 1 |
| Aktif blog | Haftada 1 | Günlük |
| E-ticaret | Haftada 1 | Günlük, yoğun dönemde daha sık |
| Üyelik / rezervasyon | Haftada 1 | Günlük + işlem kayıtları |
Buna bir de olay bazlı yedek ekleyin: tema güncellemesinden önce, PHP sürümü değiştirmeden önce, yeni bir ödeme eklentisi kurmadan önce. Bu üç anın hepsi sitenin bozulduğu klasik anlardır.
Geri yükleme provası: hiç yapmadığınız test
Test edilmemiş yedek, yedek değildir. Arşiv dosyası bozuk olabilir, SQL dosyası yarım inmiş olabilir, e-posta klasörleri hiç dahil edilmemiş olabilir. Bunu felaket anında öğrenmek istemezsiniz.
Yılda en az iki kez şu provayı yapın: bir alt alan adı ya da yerel bir sunucu ortamı açın, en son yedeği oraya kurun, ana sayfa açılıyor mu, ürünler listeleniyor mu, yönetim paneline giriliyor mu bakın. Prova sırasında not almanız gereken tek şey süredir. "Bu siteyi sıfırdan 40 dakikada ayağa kaldırabiliyorum" bilgisi, gerçek bir kesinti anında en değerli bilgidir.
Bir de yedeklerin okunabilirliğini kontrol edin: .sql.gz dosyasını açıp içinde CREATE TABLE satırlarını görüyorsanız dosya sağlamdır. 2 KB’lık bir SQL dosyası, aslında sadece hata mesajı içeriyor demektir.
Özetle
- Yedek üç parçadır: dosyalar, veritabanı, e-posta. Birini atlarsanız geri dönüş eksik olur.
- 3-2-1 kuralını uygulayın; en az bir kopya sağlayıcınızın altyapısının dışında dursun.
- Sunucu yedeği donanım arızası içindir, sizin hatanız için değil; saklama süresini öğrenin.
- Sıklığı "kaç saatlik veriyi kaybedebilirim" sorusuna göre belirleyin; güncelleme öncesi ayrıca yedek alın.
- Yılda iki kez geri yükleme provası yapın ve ne kadar sürdüğünü not edin.