Joomla CMS Web Sitesinde Teknik Yedekleme Yönetimi

Joomla tabanlı bir web sitesinde yedekleme yönetimi, yalnızca dosyaları ve veritabanını periyodik olarak kopyalamaktan ibaret değildir. Gerçek dünyada RPO/RTO hedefleri, yedeklerin bütünlüğü (integrity), şifreleme ve erişim kontrolü, offsite/immutable kopyalar, geri yükleme tatbikatları (restore drills), versiyonlu ortam stratejisi (dev–staging–prod), bağımlılık envanteri (CDN, arama, SMTP, ödeme, DAM, DNS, TLS), otomasyon ve izlenebilirlik (log/alert), hukuki gereklilikler (KVKK/GDPR veri saklama politikaları) ve runbook’lar bir bütün olarak çalışır.

1) Yedekleme Stratejisinin Amacı: RPO/RTO ile Başla

• RPO (Recovery Point Objective): Kabul edilebilir veri kaybı penceresi. Örn. 15 dk.

• RTO (Recovery Time Objective): Hizmetin yeniden ayağa kalkması için hedef süre. Örn. 30 dk.

• Joomla bağlamı: Editörlerin yoğun çalıştığı haber sitelerinde RPO küçülmeli (sık artımlı DB yedeği), kurumsal vitrin sitelerinde RTO öncelikli olabilir (önceden paketlenmiş imajlar).
  Kontrol listesi: RPO/RTO hedefleri yazılı, yönetimce onaylı mı? Panolarda (Grafana/Kibana) izleniyor mu?

---

2) 3–2–1–0 Disiplini ve Varyasyonlar

• 3 kopya: En az üç ayrı kopya (1 prod, 2 yedek).

• 2 farklı ortam/medya: Yerel disk + bulut/obje depolama (S3/compatible), veya NAS + tape.

• 1 offsite/immutable: Fidye yazılımlarına karşı WORM/immutable katman.

• 0 hata: Düzenli doğrulama (checksum/hash) ve staging restore tatbikatıyla “sıfır sürpriz”.
  Varyant: 3–2–1 + 1 sahne (staging) kurtarma provası / ayda 1.

---

3) Ne Yedeklenir? Joomla Bileşen Envanteri

• Veritabanı: Joomla DB (MySQL/MariaDB/PostgreSQL); tüm şema + veri.

• Uygulama dosyaları: /administrator, /components, /modules, /plugins, /templates, /media, /images, /language, kök configuration.php.

• Şablon override & child theme: templates/<tema>/html altındaki override’lar.

• Özel kod/komut dosyaları: cli/ betikleri, cron script’leri.

• Dış bağımlılıklar (yedek dahil değil ama “geri dönme” için şart):

  • DNS/TLS: Zone dosyaları, sertifikalar/özel anahtarlar (ayrı kasada).

  • CDN kuralları: Edge konfigürasyonları (export).

  • Arama (Solr/ES) indeksleri: Yeniden oluşturma runbook’u.

  • SMTP/Kimlik sağlayıcı ayarları: OIDC/SAML metadata.

---

4) Yedek Tipleri: Tam, Artımlı, Diferansiyel, Sürekli

• Tam (Full): Haftalık/iki haftalık; tüm dosya ve DB.

• Artımlı (Incremental): Günlük/saatlik; yalnız değişen parçalar.

• Diferansiyel: Son tam yedekten bu yana değişenler.

• Sürekli (CDC/Binlog): DB için transaction/binlog yakalama (RPO’yu dakikalara indirir).
  Öneri: “Haftalık tam + günlük artımlı dosya + 15 dakikalık DB binlog kopyalama.”

---

5) Zamanlama ve Pencere Planlaması

• Bakım penceresi: Trafiğin en düşük olduğu saat diliminde I/O dostu plan.

• Kaynak yönetimi: Yedekleme I/O’su prod performansını etkilemesin (I/O throttle, nice/ionice).

• Çakışmalar: Cron/kuyruk (media işleme, index) ile çakışmayı önle.
  Vaka: Yedekleme sırasında DB kilitlenmeleri LCP’yi bozuyordu; saat kaydırma + throttle ile normale döndü.

---

6) Depolama Hedefleri: Yerel, NAS, Obje Depolama, Tape

• Yerel disk: Hızlı ama tek noktaya bağımlı. Yalnız ilk kopya.

• NAS: Aynı veri merkezinde hızlı kurtarma. Snapshot’lar + versiyonlama.

• Obje depolama (S3/compatible): Coğrafi replikasyon, lifecycle politikası, immutable destek.

• Tape (air-gapped): Uzun saklama, düşük maliyet.
  Politika: Yaşam döngüsü (hot → warm → cold), saklama süreleri (örn. günlük 14 gün, haftalık 12 hafta, aylık 12 ay).

---

7) Sıkıştırma, Dedup ve Transfer Optimizasyonu

• Sıkıştırma: Zstd/gzip; medya için ayrı politika (zaten sıkışık).

• Dedup: Dosya düzeyinde veya blok düzeyinde yinelenenleri azaltır.

• Bant genişliği: Gece replikasyon, hız sınırlama, delta transfer (rsync/rdiff).
  Sonuç: Maliyet ve restore süresinde belirgin düşüş.

---

8) Şifreleme ve Anahtar Yönetimi

• At-rest: Sunucu/disk veya obje depolama tarafında AES-256.

• In-transit: TLS.

• Anahtarlar: KMS/Vault; erişimler “en az ayrıcalık (PoLP)” ve break-glass prosedürü ile.

• Checksum: SHA-256 hash ile bütünlük kontrolü; raporu saklayın.

---

9) Yedek “Bütünlük ve Tutarlılık” Doğrulamaları

• DB tutarlılığı: Mantıksal dump + innodb_flush_log_at_trx_commit=1 vb. ayarlar; tutarlı state.

• Dosya bütünlüğü: Manifest ve hash.

• Raporlama: Başarılı/başarısız job’lar için e-posta/Slack; hata kodu ve log saklama.
  KPI: Başarısız yedek oranı < %1; doğrulama başarısı ≥ %99.

---

10) Otomasyon ve Orkestrasyon

• Yedekleme aracı: Kurumsal (Veeam/Bacula) veya script’li (restic/borg/duplicity/rsync + mysqldump).

• IaC/Pipeline: Yedek işleri Git’te kod olarak; CI/CD ile cron/pipeline tetikleme.

• Etiketleme: Prod/staging ayrımı; job isimleri, tag’ler, saklama politikaları kodda.
  Fayda: Şeffaflık, izlenebilirlik, denetlenebilirlik.

---

11) Joomla’ya Özgü İnce Noktalar

• configuration.php gizliliği: DB bilgileri/secret anahtarlar; yedekte şifreli mi?

• Şablon override’ları: Sık değişir; versiyonlanır (Git) + yedeklenir.

• images/media: Büyük; delta transfer + CDN türevlerini yedeklemeyin (kaynak dosyalar yeterli).

• Uzantı (extension) tabloları: Sürüm uyumu için liste export edin (envanter).

---

12) Geri Yükleme (Restore) Türleri ve Senaryolar

• Tam geri yükleme: Tüm sistem (dosya + DB) → “aynı ana makine/başka ana makine”.

• Kısmi geri yükleme: Yalnız images veya tek bir tablo (örn. makale revizyonları) gibi.

• ** çıplak donanım → imaj**: IaaS/VM imajından hızlı dönüş.

• Sahte üretim (staging restore): Ayda 1, otomatik senaryo.
  Runbook: 10–20 adım, ekran görüntüsü, komutlar, kontrol listesi, hosts/DNS geçiş adımı.

---

13) Staging Restore Tatbikatı

• Amaç: RTO/RPO’yu kanıtla.

• Adımlar:

  1. En son tam + artımlı seti getir,

  2. Boş staging’e kur,

  3. configuration.php’de staging DB/URL,

  4. Cache/CDN kapalı mod,

  5. Smoke test + yönetici girişi,

  6. Loglar/hatlar temiz, görsel doğrulama.

• Rapor: Süre, adım adım kanıt, sapmalar, öneriler.

---

14) Felaket Kurtarma (DR): Sıcak/Ilık/Soğuk

• Sıcak (Hot): Replikasyon hazır, otomatik failover (RTO dakikalar). Maliyet yüksek.

• Ilık (Warm): Hazır imaj + son yedekler; hızlı kurulum (RTO saatler).

• Soğuk (Cold): Yalnız yedek; yeniden kurulum (RTO günler).
  Joomla bağlamı: Orta-ölçek projelerde “ılık” ideal; DNS TTL düşürülmüş, imzalı TLS hazır.

---

15) Bağımlılıklar: DNS, TLS, CDN, SMTP, Arama, DAM

• DNS: Zone export + düşük TTL; DR sırasında hızlı yönlendirme.

• TLS: Sertifikalar güncel; wildcard + ACME client belgeli.

• CDN: Cache ısındırma (warm-up) betikleri; purge kapsamı.

• SMTP/kimlik: IP/alan yetkileri; DR uçlarına izin.

• Arama/DAM: Yeniden indeksleme ve bağlantı doğrulama talimatı.

---

16) KVKK/GDPR: Saklama Politikası ve Maskeleme

• Saklama süreleri: İçerik ve log’lar için politika; yedeklerde PII maskeleme (staging restore için).

• Erişim denetimi: Yedeklere yalnız yetkili personel; erişim log’ları.

• Silme talepleri: Yedekler için “geriye yönelik silme” teknik olarak mümkün değil → politika ve bilgilendirme şart.

---

17) İzleme, Alarm ve Metrikler

• Metrikler: Günlük job sayısı, başarısızlık oranı, toplam yedek boyutu, dedup kazancı, RTO/RPO, restore süresi.

• Alarmlar: Başarısız iş, kapasite eşiği (%80), hash uyumsuzluğu.

• Pano: “Yedek sağlık” paneli; kırmızı/amber/yeşil göstergeler.

---

18) Performans Etkisi ve “Yedekleme Dostu” Konfig

• DB dump yöntemi: Mantıksal vs. fiziksel; çevrimdışı kilitleri en aza indirme.

• I/O profil: IOPS tavanı; yedek sırasında OPcache/PHP-FPM ayarları gözden geçmesi.

• Medya: Büyük dosyalar için artımlı/rsync; CDN tarafı yeniden üretilebilir.
  Sonuç: Kullanıcı deneyimi (LCP/INP) korunur.

---

19) Ekip ve Sorumluluk: RACI + “Break-Glass”

• RACI: Kim planlar (Responsible), kim hesabı verir (Accountable), kim danışılır (Consulted), kim bilgilendirilir (Informed).

• Break-glass: Acil durumda erişim arttırma prosedürü; süreli, log’lu, geri düşümlü.

• Eğitim: Çeyreklik “restore tatbikatı” eğitimi; yeni ekip için onboarding.

---

20) Belgeleme ve Denetlenebilirlik

• Runbook’lar: Yedek alma, staging restore, DR geçişi, DNS/TLS/SMTP/CDN, arama yeniden indeks.

• Değişiklik kayıtları: Saklama/yaşam döngüsü değişimlerinde CAB onayı.

• Denetim izi: Hangi yedek kim tarafından erişildi/geri yüklendi?

---

21) Maliyet ve ROI

• Doğrudan maliyet: Depolama, veri çıkışı, lisans/araç.

• Dolaylı kazanım: Kısa RTO → daha az kesinti, daha az itibar kaybı.

• Optimizasyon: Sıkıştırma/dedup, katmanlı saklama, “yeniden üretilebilir varlıkları yedekleme”.

---

22) Vaka Çalışması A: İçerik Ağır Haber Sitesi

• Sorun: Gece artan trafik + yedek çakışması → TTFB artışı.

• Çözüm: Yedekleme penceresi değişti, DB için binlog replikasyonu; dosya artımlı rsync’e geçti.

• Sonuç: RPO 15 dk, RTO 25 dk; LCP dalgalanmaları sona erdi.

---

23) Vaka Çalışması B: Kurumsal Portal ve Fidye Yazılımı

• Sorun: Depodaki medya şifrelenmiş, prod erişilemez.

• Çözüm: Immutable S3 kopyası + staging restore runbook; 40 dakikada geri dönüş.

• Ders: Erişim anahtarlarını KMS’e taşıma, erişim log’larına anomali alarmı.

---

24) 90 Günlük Uygulama Planı

• Ay 1: Envanter, RPO/RTO hedefleri, 3–2–1–0 tasarımı, araç seçimi, ilk tam + artımlı kurulum.

• Ay 2: Staging restore tatbikatı, immutable/offsite kopya, KVKK maskeleme akışı.

• Ay 3: DR (ılık) planı, bağımlılık runbook’ları, panolar/alarmlar, maliyet optimizasyonu.
  KPI: Başarısız yedek job oranı, ortalama restore süresi, doğrulama başarı yüzdesi.

---

25) Sık Yapılan Hatalar ve Karşı Önlemler

• Hata: “Yedeği aldık, test etmeye gerek yok.” → Önlem: Aylık staging restore zorunlu.

• Hata: Tek ortama güvenmek. → Önlem: Offsite + immutable katman.

• Hata: PII’yi çıplak taşımak. → Önlem: Şifreleme + KMS + erişim logları.

• Hata: CDN/arama/DNS’i unutarak “geri döndük sanmak.” → Önlem: Bağımlılık runbook’ları.

• Hata: Yedekleri aşırı büyütmek. → Önlem: Delta transfer, medya için politika, lifecycle.

---

Sonuç: Yedek Değil, Geri Dönüş Yeteneği Satın Alın

Joomla sitenizde yedekleme yönetimini “dosyaları bir yere atmaya” indirgerseniz, en kritik anda yalnızca umut yedeklenmiş olur. Oysa profesyonel yaklaşım; RPO/RTO hedefleri, 3–2–1–0 disiplini, immutable/offsite kopyalar, otomasyon ve doğrulama, staging restore tatbikatı, DR senaryoları, bağımlılık runbook’ları ve gizlilik uyumunu içeren bir dayanıklılık mimarisi kurmaktır. Böyle bir mimariyle yedekleriniz yalnız “var” olmaz, ölçümlenmiş sürede geri dönebilir hale gelir.

Önerimiz: Hemen bugün RPO/RTO hedeflerini yazılı hale getirin, tam + artımlı + binlog kombinasyonunu devreye alın, immutable/offsite kopyayı ekleyin ve bir staging restore tatbikatı yapın. Ardından bağımlılık runbook’larını tamamlayın ve panolara yedek sağlık metriklerini asın. Böylelikle Joomla projeniz yalnızca veri kaybına değil, iş kesintisine karşı da dirençli bir platforma dönüşecektir.

Bill Gates Web: Profesyonel Çözümler Sunan Güvenilir Partneriniz

Bill Gates Web, dijital dünyada varlık gösteren herkes için kapsamlı çözümler sunan öncü bir platformdur. Web tasarım, yazılım geliştirme, uygulama ve programlama gibi birçok alanda uzmanlaşmış olan ekibimiz, sizin işinizi büyütmeniz için gereken her şeyi sunmak için burada. Sektördeki en son teknolojilere hakim olan ekibimiz, projenizin başarılı bir şekilde hayata geçirilmesini sağlamak için elinden gelenin en iyisini yapar.

Dijital Varlığınızı Güçlendirecek Profesyonel Dokunuşlar

Bill Gates Web olarak, işinizi bir adım öteye taşıyacak benzersiz çözümler sunuyoruz. İhtiyaçlarınıza özel olarak tasarlanmış web siteleri, kullanıcı dostu arayüzler, özelleştirilmiş yazılımlar ve mobil uygulamalarla dijital varlığınızı güçlendiriyoruz. Ayrıca, itibar danışmanlığı hizmetimizle markanızın çevrimiçi itibarını korumak ve geliştirmek için size rehberlik ediyoruz.

İlerlemenin Anahtarını Bugün Yakalayın

Siz de işinizi dijital dünyada büyütmek ve ilerlemek istiyorsanız, Bill Gates Web sizin için doğru adres. Profesyonel ekibimizle çalışarak, rekabetin önüne geçecek çözümlerle tanışabilir, başarıya giden yolda adımlarınızı sağlam atabilirsiniz. Hemen bizimle iletişime geçin ve dijital dünyadaki potansiyelinizi keşfedin!