- Ana sayfa
- CMS yedekleme
CMS yedekleme: haber arşivini kaybetmemek için yedek ve geri yükleme planı
Kısa cevap
İyi bir CMS yedekleme planı dört soruya yanıt verir: neyi (veritabanı + yükleme klasörü + tema/eklenti + yapılandırma), ne sıklıkla (haber sitesinde günlük tam + saatlik veritabanı), nereye (3-2-1: üç kopya, iki ortam, biri site dışı) ve nasıl geri döneceğiz (düzenli geri yükleme provası). Yedek alınıyor ama hiç geri yüklenmemişse plan yoktur.
Neyi yedeklemeli?
- Veritabanı: haberler, yazarlar, kategoriler, yorumlar, ayarlar. En sık değişen ve en kritik parça.
- Yükleme klasörü: görseller, videolar, PDF'ler; genellikle en büyük hacim. Görsel arşivi kaybolursa haberler "kırık" kalır.
- Tema ve eklentiler: özellikle özelleştirilmiş alt tema ve ücretli eklenti dosyaları.
- Yapılandırma:
wp-config.php/settings.php, sunucu yapılandırması, yönlendirme kuralları, çevre değişkenleri, API anahtarları (şifreli). - Dış bağımlılıklar: CDN'deki görseller, üçüncü taraf servislerdeki veriler (bülten listesi, yorum servisi) — bunların da dışa aktarımı planlanmalı.
Ne sıklıkla?
| Site türü | Veritabanı | Dosyalar | Saklama |
|---|---|---|---|
| Günde onlarca haber giren haber sitesi | Saatlik (artımlı) + günlük tam | Günlük (artımlı) | 30 gün günlük, 12 ay aylık |
| Günde birkaç yazı yayımlayan site | Günlük | Haftalık | 30 gün |
| Nadiren değişen kurumsal site | Haftalık + her değişiklikte | Her değişiklikte | 90 gün |
Kural: kabul edilebilir veri kaybı (RPO) ne kadarsa yedek sıklığı o kadar olmalı. Bir haber sitesinde "son bir saatin haberlerini kaybetmek" bile pahalıdır.
Nereye? 3-2-1 kuralı
En az üç kopya, en az iki farklı ortamda, en az biri site dışında (başka sağlayıcı ya da bulut depolama). Yedeği aynı sunucuda tutmak yedek değildir: sunucu giderse yedek de gider. Site dışı kopya için nesne depolama (S3 uyumlu servisler), ayrı bir barındırma hesabı ya da sağlayıcının farklı bölgedeki depolaması kullanılır. Yedekler şifrelenmeli, erişim anahtarları sitenin kendisinde saklanmamalıdır (ele geçirilen site yedeği de silebilir).
Geri yükleme provası
- Test ortamı kurun. Canlı siteyle aynı PHP/veritabanı sürümünde boş bir sunucu ya da alt alan adı.
- Son yedeği geri yükleyin. Veritabanı + dosyalar; adres değişikliğini (canlı → test) yapın.
- Kontrol edin. Ana sayfa, bir kategori, son 10 haber, görseller, panel girişi, kullanıcı rolleri.
- Süreyi ölçün. Geri yükleme kaç dakika sürdü? Bu sizin kurtarma süreniz (RTO).
- Kaydedin ve tekrarlayın. Ayda bir; büyük güncelleme ya da taşıma öncesinde mutlaka.
Otomatik geri yükleme provası yapan sağlayıcılar vardır: yedek her gece ayrı bir ortama geri yüklenir ve doğrulanır. Bu, "yedek bozuk çıktı" sürprizini ortadan kaldırır.
Sistemlere göre araçlar
- WordPress: UpdraftPlus, Duplicator, BlogVault, Jetpack VaultPress; yönetilen barındırmaların kendi yedekleri. Site dışı depolama ayarını unutmayın.
- Drupal: Backup and Migrate modülü, Drush ile veritabanı dökümü, sunucu düzeyinde dosya yedeği.
- Joomla: Akeeba Backup (tam site paketi), yönetici panelinden dışa aktarım.
- Ghost: JSON içerik dışa aktarımı +
content/klasörü + MySQL dökümü; Ghost(Pro) günlük yedek alır. - Statik üreticiler: içerik git deposunda; yedek = depo + CI yapılandırması.
- Hazır scriptler: çoğunda yedek özelliği yoktur; sunucu düzeyinde cron ile çözülür. Bkz. haber scripti.
Yönetilen hizmetlerde sorulacak sorular
- Yedek ne sıklıkla alınıyor; veritabanı ve dosyalar ayrı mı?
- Kaç gün saklanıyor; farklı bölge/sağlayıcıda kopya var mı?
- Geri yükleme provası yapılıyor mu; ne sıklıkla?
- Tek bir haberi ya da silinen içeriği geri getirebiliyor muyum (nokta kurtarma)?
- Sözleşme biterse tam yedeği hangi biçimde alırım?
Sık yapılan hatalar
Dikkat
- Yedeği yalnızca aynı sunucuda tutmak.
- Yedek dosyasını herkese açık klasörde bırakmak (
/backup.zipindirilebilir olur). - Hiç geri yükleme denemeden "yedeğimiz var" demek.
- Görsel klasörünü "çok büyük" diye yedek dışında bırakmak.
- Yedek bildirimlerini okumamak; aylardır başarısız olan görevi fark etmemek.
Yedekten geri dönüş senaryoları
| Olay | Ne geri yüklenir? | Not |
|---|---|---|
| Bir haber yanlışlıkla silindi | Yalnızca o kayıt (çöp kutusu / revizyon / nokta kurtarma) | Tam geri yükleme gerekmez; CMS'in silinen içerik kurtarma özelliği varsa saniyeler sürer |
| Eklenti güncellemesi siteyi bozdu | Dosyalar (eklenti klasörü) ya da tam dosya yedeği | Veritabanını geri almayın; güncellemeden sonraki haberler kaybolur |
| Site ele geçirildi | Temiz tarihli tam yedek (dosya + veritabanı) | Önce açığı kapatın; aksi hâlde yeniden ele geçirilir |
| Sunucu/sağlayıcı çöktü | Site dışı tam yedek, yeni sunucuya | DNS değişikliği gerekir; TTL düşük tutulmuşsa hızlı |
| Taşıma başarısız oldu | Taşıma öncesi "altın yedek" | Taşıma günü tam yedek alınmadan başlamayın |
Yedek güvenliği ve saklama
Yedek dosyası, sitenin kendisi kadar hassastır: veritabanı dökümünde kullanıcı e-postaları, parola karmaları ve API anahtarları bulunur. Yedekleri şifreleyin, erişimi ayrı kimlik bilgileriyle sınırlayın, web kökünde (/public_html/backup/ gibi) asla tutmayın ve indirme bağlantılarını herkese açık bırakmayın. Saklama süresi kişisel veri içeriyorsa aydınlatma metninizle uyumlu olmalıdır; "sonsuza kadar sakla" KVKK açısından da sorunludur. Yedek bildirimlerini okuyan bir kişi belirleyin; aylardır sessizce başarısız olan görev en sık görülen kayıp nedenidir.
Yedekleme, güvenlik planının son savunma hattıdır: CMS güvenliği sayfasındaki 12 önlemin onuncusu bu sayfadır. Taşıma öncesi yedek için CMS taşıma; rollerle birlikte kimin yedek alıp geri yükleyebileceği için CMS kullanıcı rolleri.
Sık sorulan sorular
- Barındırma sağlayıcısının yedeği yeterli mi?
- Hayır; sağlayıcı yedeği genellikle kısa süreli, aynı altyapıda ve geri yükleme garantisi olmadan tutulur. Kendi site dışı kopyanız olmalı.
- Yedek dosyası ne kadar büyür?
- Görsel arşivi belirleyicidir; artımlı yedek yalnızca değişen dosyaları alarak boyutu küçültür.
- Yedeği kim geri yükleyebilmeli?
- En az iki yetkili kişi; süreç yazılı ve prova edilmiş olmalı.
- Yedek ne kadar sıklıkla test edilmeli?
- Ayda bir tam geri yükleme provası; her büyük güncelleme ve taşıma öncesinde ek prova. Sonuçları tarih ve süreyle kaydedin.
- Yönetilen hizmette yedek sorumluluğu kimde?
- Sağlayıcıda; ancak sıklık, saklama süresi, prova ve çıkış biçimi sözleşmede yazmalı.
Haber sitesi için yönetilen alternatif
Yukarıdaki sistemi kurmak, güncellemek ve güvende tutmak sizin ya da bir geliştiricinin işi olur. Bu yükü istemeyen haber yayıncıları için kendi ürünümüz KEYDAL Haber Yazılımı yönetilen bir alternatiftir: yazılım + hosting birlikte (₺2.500 + KDV / ay yazılım; üstüne aynı tutarda hosting), kurulum otomatik, manşet/zamanlanmış yayın/roller/haber sitemap'i ve Türk basın mevzuatı kayıtları çekirdekte. Karşılığında açık kaynak esnekliğinden ve kendi temanızı yükleme özgürlüğünden vazgeçersiniz. İki yolu aynı ölçütlerle karşılaştırdığımız sayfa: en iyi CMS hangisi; ürünün sınırlarıyla birlikte anlatımı: KEYDAL ürün sayfası.
Kaynaklar
- WordPress.org, WordPress Backups — https://developer.wordpress.org/advanced-administration/security/backup/
- Drupal.org, Backup and Migrate — https://www.drupal.org/project/backup_migrate
- Akeeba Backup for Joomla — https://www.akeeba.com/products/akeeba-backup.html
- Ghost, Import/Export dokümantasyonu — https://ghost.org/help/the-importer/
Bu sayfa bilgilendirme amaçlıdır; hukuki danışmanlık değildir. Ayrıntı: Yasal uyarı.