Drupal Web Sitesinde Teknik Yedekleme Stratejileri

Drupal ekosisteminde (çekirdek, modüller, tema/alt tema, konfigürasyon, içerik varlıkları, dosya sistemi, veritabanı, arama/queue/cron, CDN/edge) değişim süreklidir. Bu canlılık; güvenlik yamaları, sürüm yükseltmeleri, içerik kampanyaları, entegrasyon güncellemeleri ve kimi zaman hatalı dağıtımlar anlamına gelir. Yedekleme stratejisi, yalnızca dosyaları bir yere kopyalamak değildir. Kapsam (Neyi yedekliyoruz?), sıklık (Ne kadar sık?), saklama politikası (Ne kadar tutuyoruz?), konum (Nerede?), bütünlük ve şifreleme (Gizlilik ve değişmezlik?), geri yükleme tatbikatı (Çalıştığına dair kanıt) ve RTO/RPO hedeflerinden oluşan çok katmanlı bir disiplindir.

1) Varlık Envanteri ve Risk Sınıflandırması

Neden? Yedekleme kapsamı, Drupal’in yalnız dosya + DB’den ibaret olmadığı gerçeğine göre belirlenmeli.

• Zorunlu kalemler:

  • Veritabanı: Drupal şeması + içerik (node, taxonomy, menu, block config), kullanıcılar, izinler.

  • sites/default/files (public): Medya orijinalleri, üretilmiş stiller (gerekçe ile), dosya referansları.

  • sites/default/private (private): Hassas dosyalar.

  • Kod & konfig: Tema/alt tema, custom modüller, config/sync veya konfig depoları, composer.lock.

  • Arama/queue/cron: Yeniden üretilebilir (genelde yedeklenmez) ama dokümante edilir.

  • Edge/CDN objeleri: Kaynak dosyalardan üretildiği için çoğu zaman yedeklenmez; purge/warm-up runbook’u tutulur.

• Hassasiyet etiketleri: PII içeren DB ve private dosyalar “yüksek” etikette; log arşivleri “orta”; cache/stil “düşük”.

---

2) 3–2–1–0 Prensibi: “Kopya” Değil, “Kurgulanmış Güvence”

• 3 kopya: Canlı + iki yedek.

• 2 farklı ortam: Farklı depolama türleri (ör. obje depolama + blok depolama).

• 1 offsite/immütabl: Farklı bulut/bölgede değiştirilemez (WORM) katman.

• 0 sürpriz: Aylık staging restore tatbikatı ile kanıt.
  Not: “3–2–1” tek başına yetmez; –0 (doğrulama) işin özüdür.

---

3) RTO/RPO Hedeflerinin Belirlenmesi

• RTO (Recovery Time Objective): Geri dönüşte kabul edilen maksimum süre (örn. 2 saat).

• RPO (Recovery Point Objective): Veri kaybında kabul edilen maksimum eskilik (örn. 15 dk).

• Örnek: Haber portalı için RPO 15 dk, kurumsal vitrin için RPO 24 saat yeterli olabilir.
  Karar: Bu hedefler, yedekleme sıklığı ve topolojisini (tam/artımlı/sürekli) belirler.

---

4) Yedek Türleri: Tam, Artımlı, Sürekli (PITR)

• Tam yedek: Kod+konfig+DB+dosyalar. Haftalık/aylık.

• Artımlı (incremental): Son yedekten bu yana değişen bloklar/objeler. Günlük/4–6 saatte bir.

• Sürekli (PITR): DB için binlog/WAL tabanlı sürekli replikasyon. RPO hedefi çok sıkıysa zorunlu.
  Denge: DOSYA + DB aynı anda tutarlı alınmalı (quiesce/lock veya transaction snapshot).

---

5) Veritabanı Yedekleme: Tutarlılık ve Kilit Yönetimi

• Teknik:

  • MySQL/MariaDB: mysqldump --single-transaction --quick --routines veya mümkünse dondurmadan alınan anlık görüntü (snapshot).

  • Büyük verilerde fiziksel yedek (Percona XtraBackup gibi) düşünülebilir.

• Kilitleme: Yoğun sitelerde uzun süren kilitlerden kaçın; tek seferde ve düşük etkili yöntemleri tercih et.

• PITR: Binlog arşivi; kesinti anına dönmek için gereklidir.
  Kontrol: Yedek boyutu/anlamlılık; test restore’da drush status ve kritik sayfalar.

---

6) Dosya Sistemi: Public, Private ve Türetilmiş İçerik

• Public (sites/default/files):

  • Orijinaller mutlaka yedeklenir.

  • Türetilmiş stiller (image styles) tekrar üretilebilir; zorunlu değil. Depo–bant genişliği dengesine göre karar verilir.

• Private: PII/sözleşme gibi hassas içerikler; şifreli yedek ve sıkı erişim şart.

• Büyük medya: Video/orijinal görüntü arşivleri için yaşa-dayalı (lifecycle) politikalar (sıcak → soğuk arşiv).
  İpucu: Yedeklemede symlink/harici storage kullanan yapılarda bağ çözümleri belgelensin.

---

7) Kod ve Konfigürasyon: Ayrıştır, Versiyonla, Kanıtla

• Kod: Git repo; composer.lock ile tekrarlanabilir kurulum. Yedekte repoya ek olarak paketlenmiş artefakt saklanabilir.

• Konfig: Drupal Configuration Management (CMI) ile config/sync dizini; ortamlar arası taşınabilir tutun.

• Avantaj: Restore’da kod+konfig’i repo/artefaktan, veriyi yedekten alarak tutarlı geri dönüş.

---

8) Şifreleme, Anahtar Yönetimi ve İmmütabilite

• At-rest şifreleme: AES-256; anahtarlar KMS/Vault’ta; erişim log’lu.

• In-transit: TLS; offsite’a giderken şifreli aktarım.

• Immütabl depolama (WORM): Fidye yazılımlarına karşı değiştirilemez yedek katmanı.
  Politika: Yedekleri silme yetkisi sınırlı ve iki onaylı olsun.

---

9) Zamanlama, Pencere ve Performans Etkisi

• Pencere: Trafiğin düşük olduğu saatler; cron/queue ile çakışmasın.

• Kısıtlama: I/O ve CPU limitleri; DB snapshot sırasında kısa kilitler.

• Ayrı düğüm: Mümkünse yedeklemeyi replika DB üzerinden al.

---

10) Saklama Politikası ve Yaşa-Dayalı Arşiv

• Kısa dönem: Saatlik/günlük artımlı → 7–14 gün.

• Orta dönem: Haftalık tam → 4–8 hafta.

• Uzun dönem: Aylık tam → 6–12 ay (uygulama gereksinimine göre).
  Dikkat: KVKK/GDPR nedeniyle gereğinden uzun tutmayın; saklama süreleri veri sınıfına göre tanımlansın.

---

11) DR (Felaket Kurtarma) Topolojileri: Sıcak–Ilık–Soğuk

• Sıcak (hot): Anlık replikasyon; RTO dakikalar; maliyet yüksek.

• Ilık (warm): Günlük/talep üzerine restore; RTO saatler.

• Soğuk (cold): Arşivden geri dönüş; RTO günler.
  Karar: İş kritikliğine göre karma topoloji (örn. DB sıcak, dosya ılık) seçilebilir.

---

12) Çoklu Site/Çok Dilli Yapılarda Yedekleme

• Paylaşımlı kod, ayrı DB/dosya: Her sitenin ayrı DB + dosya kökü yedeklenmeli.

• Çapraz bağımlılıklar: Ortak medya/CDN politikaları; restore sırasında site-bazlı ayrım net olmalı.

• Konfig split: Site-bazlı config dizileri; yedek–restore senaryosunda karışıklığı önler.

---

13) Arama, Queue ve Cache Katmanları

• Arama indeksleri: Genellikle yeniden oluşturulur (backup yerine runbook).

• Queue iş yükü: Restore sonrası işçileri durum kontrolü ile açın; duplike çalışmasın.

• Cache/CDN: Geri dönüşten sonra hedefli purge + warm-up planı.

---

14) Yedekleme Otomasyonu ve IaC

• Otomasyon: Cron/scheduler, yedekleme komutları, checksum, bütünlük doğrulaması, başarısızlık alarmı.

• IaC: Yedekleme topolojisi (bucket, lifecycle, immutability) altyapı olarak kodda (Terraform vb.).

• Rapor: Günlük/haftalık özet: Başarılı yedek sayısı, boyutlar, checksum, uyarılar.

---

15) Bütünlük Doğrulama ve Checksum

• Hash: SHA-256/SHA-512; her yedeğin manifest dosyası.

• Doğrulama: Offsite kopya yeniden hesaplanır; farklılıkta alarm.

• Medya örneklemesi: Rastgele seçilen orijinallerde açılabilirlik testi.

---

16) Staging Restore Tatbikatı: “0 Sürpriz”in Kanıtı

• Aylık tatbikat: Son tam + gerekli artımlı yedeklerle staging’de geri yükleme.

• Protokol:

  1. Boş staging → kod/konfig kurulumu,

  2. DB restore + drush updb -y (gerekliyse),

  3. Dosya restore,

  4. drush cr, site sağlık testleri,

  5. Kimlik/URL ayarları,

  6. Smoke: ana sayfa, içerik, form, login, arama, sitemap/robots, JSON-LD, CWV/Lighthouse kısa testleri.

• Kayıt: RTO/RPO ölçüleri, hatalar, düzeltici aksiyonlar (CAPA).

---

17) Runbook’lar: Adım Adım “Nasıl”

• Yedek alma runbook’u: Komutlar, değişkenler, saklama yolları, hatada geri dönüş.

• Restore runbook’u: “Büyük resim” akış ve kontrol listeleri.

• İletişim planı: Kesinti/geri dönüş sırasında paydaş bilgilendirmesi (durum sayfası, beklenen süre, etki).

---

18) Güvenlik Boyutu: Erişim, Yetki ve Günlükleme

• Asgari ayrıcalık (PoLP): Yedek depolarına yalnız yetkili servis hesapları.

• Anahtar rotasyonu: Erişim anahtarları periyodik değişsin.

• Günlükleme: Kimin ne zaman indirdiği/sildiği log’lu; immütabl katmanda silme kapısı kapalı.

---

19) Yedek Boyutu ve Maliyet Optimizasyonu

• Deduplicasyon: Obje depolamada versiyonlama + lifecycle ile maliyet düşer.

• Stillerin yeniden üretimi: Türetilmiş dosyaları yedeklemeyerek depolama azalır (karşılığında restore süresi uzar).

• Bölgesel fiyat farkları: Offsite bölge seçimi (latency + maliyet dengesi).

---

20) Performans–Yedekleme Etkileşimi

• Canlı yük: Yedekleme yoğun I/O oluşturur; pencere + hız sınırlaması.

• Replika DB: Yoğun sitelerde yedeklemeyi replika üzerinden al; PITR için binlog yine master’da tutulur.

• Edge etkisi: CDN ile anonim trafik yükü düşükse pencere esneyebilir.

---

21) Yasal ve Gizlilik (KVKK/GDPR)

• Saklama süresi: PII içeren veriler için gereğinden uzun saklamayın.

• Maskeleme: Staging restore’da PII maskelenir (e-posta/telefon/ID).

• Talepler: Silme talebi → yedeklerden geriye dönük imha pratik zordur; politika ve şeffaf bilgilendirme gerekir.

---

22) İnsan Hatasını Azaltmak: Onay Kapıları ve İki Kişi Kuralı

• Önemli işlemler: Yedek silme, immütabl pencere değişimi, anahtar rotasyonu → iki onay.

• Check-list: Restore başlamadan “son iyi yedek”in tarih/hash’i yazılı onaylanır.

---

23) İzleme, Alarm ve Raporlama

• Alarm: Başarısız yedek, checksum uyuşmazlığı, offsite replikasyon gecikmesi, yedek boyut anomali artışı.

• Panolar: Son başarılı yedek zamanı, toplam boyut, RPO tahmini, immütabl pencere durumu.

• Yönetim özeti: Aylık “yedek sağlığı raporu” (SLA, olaylar, tatbikat çıktıları).

---

24) Vaka A: Medya Ağır Portal – “Stiller Yedek mi?”

Sorun: Petabayt seviyesine giden stil üretimleri depolamayı patlatmış.
Çözüm: Yalnız orijinaller yedeklendi; stil klasörleri exclude. Restore sonrası queue ile yeniden üretim + CDN warm-up.
Sonuç: Depolama %62 azaldı; restore RTO’su 35 dk uzadı (kabul edilebilir).

---

25) Vaka B: Hatalı Dağıtım Sonrası Hızlı Geri Dönüş

Sorun: Tema güncellemesi kritik formu bozdu; 5xx arttı.
Çözüm: Kod rollback + DB değişikliği yoksa yalnız kod geri alındı; CDN hedefli purge.
Ders: Kod–DB bağımsızlığı, küçük artımlı dağıtımlar ve yedek–restore bağı kopmamalı.

---

26) Vaka C: Ransomware ve İmmütabl Yedek

Sorun: Barındırma sağlayıcısının paylaşımlı dosya sistemi şifrelenmiş.
Çözüm: Offsite immütabl objeden temiz kopya; anahtarlar KMS’te; 3 saat içinde RTO.
Ders: WORM katmanı ve iki onaylı silme politikası hayat kurtarır.

---

27) 90 Günlük Uygulama Planı (Örnek)

• Ay 1: Varlık envanteri + risk sınıflandırması; RTO/RPO hedefleri; 3–2–1–0 tasarımı; DB ve dosya yedek akışlarının PoC’u; checksum & raporlama iskeleti.

• Ay 2: Offsite immütabl katman; lifecycle & saklama politikaları; staging restore tatbikatı v1; maskeleme script’leri; alarm/pano kurulumu.

• Ay 3: PITR (binlog) devreye alma; replikadan yedek; maliyet optimizasyonu (stiller exclude + warm-up); runbook’ların dondurulması ve ekip eğitimi.
  KPI: Son 30 gün içinde en az 1 başarılı staging restore, başarısız yedek oranı < %1, RPO hedef ≤ 15 dk/24 saat (senaryoya göre), immütabl offsite kapsama %100.

---

Sonuç: Yedekleme Bir Dosya Kopyası Değil, Kanıt Üreten Bir Operasyon

Drupal’da yedekleme stratejisi, “olası felakete karşı sigorta” değil, günlük operasyonun parçasıdır: varlık envanteri ve hassasiyet sınıflandırmasıyla başlar; 3–2–1–0 ve RTO/RPO hedefleriyle ölçülebilir hale gelir; tutarlı DB+dosya yaklaşımlarıyla teknik doğruluk kazanır; şifreleme/immütabilite ile güvenlik; staging restore tatbikatları ile kanıt üretir; rapor/panolarla görünür olur; runbook ve eğitimle sürdürülebilir kılınır.

Öneri: Bugün, envanteri çıkarın ve verilerinizi hassasiyet etiketleriyle sınıflandırın. RTO/RPO hedeflerini yazılı hale getirip 3–2–1–0 topolojinizi çizin. Checksum ve immütabl offsite katmanını açın; önümüzdeki hafta bir staging restore planlayın. Üç ay içinde, “yedek aldık mı?” sorusuna değil, “Hangi yedekten kaç dakikada, hangi kanıtlarla döndük?” sorusuna net yanıt veren bir sisteme sahip olacaksınız.

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!