Drupal Web Sitesinde Teknik Yedekleme ve Kurtarma

Drupal; esnek içerik modellemesi (Content Types, Fields, Taxonomy), güçlü izin sistemi (Roles & Permissions), modüler mimarisi ve konfigürasyon yönetimi (Configuration Management) sayesinde kurumsal ölçekte güvenilen bir CMS’tir. Ancak bu gücün sürdürülebilirliği, yalnızca modül sürümleri veya sunucu ayarlarıyla değil, yedekleme ve kurtarma disiplininin ne kadar yerleşik olduğuyla ölçülür. Bir “backup.zip” dosyasını indirip rahatlamak, modern Drupal ekosisteminde yanıltıcı bir güven duygusudur; çünkü kurtarma başarısı yalnızca dosyaların varlığına değil, geri yükleme süre hedefleri (RTO), veri kaybı hedefleri (RPO), tutarlılık testleri, felaket senaryosu tatbikatları, konfigürasyon-sunum ayrımı ve otomasyona bağlıdır.
1) Stratejik Çerçeve: RPO, RTO ve Kurtarma Senaryoları
Neden? Yedekleme başarısı yalnızca dosya sağlamlığı değil, zamansal hedeflerin yakalanmasıdır.
-
RPO (Recovery Point Objective): Kabul edilebilir maksimum veri kaybı penceresi (ör. 15 dk/1 saat).
-
RTO (Recovery Time Objective): Sistemin yeniden ayağa kalkması için hedef süre (ör. 30 dk/2 saat).
-
Senaryolar: (a) Küçük ölçekli geri dönüş (yanlış içerik silme), (b) Büyük sürüm güncellemesi sonrası bozulma, (c) Sunucu/deprem/siber saldırı gibi felaket durumları.
Uygulama örneği: Orta ölçekli bir haber sitesinde RPO=15 dk, RTO=45 dk hedefi belirlendi. Bu hedefler, artımlı veritabanı yedeği ve dosya delta yedekleri ile desteklendi; DR bölgesinde sıcak standby hazırlandı.
2) Drupal’ın Yedekleme Bileşenleri: “Neyi” Yedekliyoruz?
Kapsam belirleme, tutarlılığın anahtarıdır:
-
Veritabanı: Tüm içerikler, kullanıcılar, yapılandırmaların bir kısmı (Drupal 8+’da Config Export ile ayrışabilir).
-
Dosya sistemi:
sites/default/files
(kullanıcı yüklemeleri, stil varyantları),private://
yolundaki gizli dosyalar. -
Konfigürasyon paketleri:
drush cex
/drupal config:export
ileconfig/sync
klasörü. -
Kod tabanı: Çekirdek, modüller, temalar (genelde Git ile versiyonlanır; yine de snapshot yararlıdır).
-
Ortam ve sırlar:
.env
, settings.php’deki veritabanı bilgileri, API anahtarları (kod dışı güvenli kasada).
Vaka: Yalnızca veritabanını yedekleyen bir ekip, medya dosyalarının kayıp olduğunu DR’da fark etti. Dosya sistemi ayrı politika ile dahil edilince kurtarma tam hale geldi.
3) 3–2–1 Kuralı ve Depolama Topolojisi
3–2–1: En az 3 kopya, 2 farklı ortam, 1 offsite.
-
Yerel + uzak depolama: Yerel disk + bulut nesne depolama (S3/GCS) + kurum içi NAS.
-
Versiyonlama ve immutability: Ransomware riskine karşı immutability (WORM) ve Object Lock.
-
Bölgesel kopyalar: DR için farklı coğrafi bölgede replikasyon.
Uygulama: Günlük artımlı (DB + files delta), haftalık tam yedek (DB + files full). Aylık arşiv, 3 ay saklama; kritik ortamlarda 6–12 ay.
4) Veritabanı Yedekleri: Sıcak, Ilık ve Soğuk Seçenekler
-
Sıcak kopya (replica): Okuma replikası; anlık failover ile RTO’yu düşürür (tam yedek yerine değildir).
-
Mantıksal döküm:
mysqldump --single-transaction
/pg_dump
ile artımlı strateji. -
Fiziksel snapshot: LVM/ZFS snapshot’ları; yüksek hacimli sitelerde hız sağlar.
Kontrol listesi: Transaction tutarlılığı, karakter seti/kolasyon, büyük tablolar için --quick
/--compress
, döküm parçalara bölme.
5) Dosya Sistemi Yedekleri: Public, Private ve Stil Türevleri
-
sites/default/files
: Public yüklemeler ve türetilmiş stil klasörleri (image styles). -
private://
yolunun yedeği: KVKK/GDPR kapsamında erişim kontrolü ve şifreli depolama. -
Delta yedekleri: rsync/rdiff-backup ile yalnız değişen blokları aktarma, maliyeti düşürür.
Vaka: E-ticaret türevi bir Drupal kurulumunda kullanıcı sözleşmeleri private://
altında idi; şifreli offsite ile uyum sağlandı.
6) Konfigürasyon Yönetimi (CMI) ve Yedekleme
Drupal 8+ ile gelen Configuration Management:
-
Export/Import:
drush cex
(export) vedrush cim
(import) ileconfig/sync
klasörü tamamen versiyonlanır. -
Ortam ayrımı: Prod/Staging/Dev için farklı
settings.php
veconfig_split
profilleri. -
Yedekleme bağı: Kod depo + config/sync + ortam sırları birlikte düşünülür.
Uygulama: Tema ayarları, görüntü stilleri, içerik türü alanları cex
ile dışa alınır; DB’den bağımsız konfigürasyon kurtarılabilir.
7) Drush ve Otomasyon Script’leri
Drush yedeklemeyi tekrarlanabilir kılar:
-
Veritabanı dökümü:
drush sql:dump --gzip --result-file=...
-
Dosya eşitleme:
drush rsync @prod:%files @stage:%files
-
Bakım modu: Güncelleme/restore öncesi
drush sset system.maintenance_mode 1
Uygulamalı örnek: Gece 03:00’te cron ile Drush komut zinciri: backup DB → delta files → rapor e-postası → eski yedek sınırını aşanları temizle.
8) CI/CD Boru Hattı: Test Edilebilir Yedekleme
-
Pipeline aşamaları: Lint → Build → Test → Package → Deploy → Backup (öncesi/sonrası) → Smoke Test.
-
Otomatik doğrulama: Yedekten staging’e otomatik restore testi (haftada 1) ve raporlama.
-
Artifact saklama: CI’da DB dump ve config paketlerini zaman sınırlı saklama.
Vaka: Bir ajans, CI’da aylık restore testini otomatize etti; kırık konfigürasyonlar prod’a ulaşmadan yakalandı.
9) Güvenlik, Şifreleme ve Erişim Yönetimi
-
At-rest şifreleme: Bulut nesne depolamada KMS ile sunucu taraflı şifreleme; hassas yedekler için istemci taraflı ek şifreleme.
-
Anahtar döngüsü: Anahtar rotasyonu, erişim en az ayrıcalık (PoLP).
-
İzleme: Yedek erişim log’larını merkezi sistemde tutun; anormal erişim uyarıları.
Örnek: private://
dump’ları ek şifrelemeyle ayrı bir bucket’ta. Anahtar erişimi yalnız DR ekibine.
10) Felaket Kurtarma (DR) Mimarisi ve Çalıştırma Modeli
-
Sıcak/ılık/soğuk DR: Trafik kritikse sıcak DR (anlık failover), değilse ılık/soğuk strateji yeterli.
-
Replikasyon: Dosya ve DB replikasyonu; S3 cross-region + veritabanı asenkron replikası.
-
Runbook: DR devreye almanın adımları, sorumlular, iletişim zinciri, karar eşikleri.
Uygulama: DNS failover + kısa TTL, load balancer konfigürasyonu ve infrastructure-as-code ile bir tuşla DR ayağa kaldırma.
11) Tutarlılık ve Bütünlük Testleri
-
Checksum: Yedek dosyalarında SHA256/MD5 hash ve periyodik doğrulama.
-
Restore denemeleri: Staging’e tam restore + kritik sayfa duman testleri (ana sayfa, arama, giriş, içerik oluşturma).
-
Uygulama logları: Geri yükleme sonrası PHP/Drupal log’larında hata taraması.
Vaka: Görsel stilleri yeniden üretilmeden dönülen yedekler CLS yapıyordu; restore hattına “styles flush & rebuild” eklendi.
12) İçerik Akışı ve Medya Yaşam Döngüsü
-
Büyük medya depoları: CDN/ofis dışı depolama ile orijinal dosyayı koruyup stil türevlerini on-demand üretmek.
-
Yaşlandırma: 1+ yıl eski ham dosyaları arşiv/nearline depoya taşıma.
-
Yeniden üretim: Image styles/derivatives temizliği ve yeniden oluşturma rutinleri.
Örnek: Seçilen medya türleri için “hot” ve “cold” depolama katmanı maliyeti %40 azalttı.
13) Modüler Bağımlılıklar: Arama, Ödeme, Entegrasyonlar
-
Yedekleme kapsamı: Solr/Elastic indexler, ödeme geçitlerinin webhook’ları, harici raporlar.
-
Kurtarma planı: Indexler yedekten mi yoksa reindex ile mi geri getirilecek?
-
SLA ve senkronizasyon: Yedek restore sonrası webhook re-subscription ve replay adımlarını unutmayın.
Vaka: E-ticaret entegrasyonunda sipariş bildirimleri kayboldu; restore sonrası “webhook replay” akışı plana eklendi.
14) Çoklu Ortam (Dev/Staging/Prod) ve Veri Maskesi
-
Maskeleme: Staging’e prod DB kopyalanırken PII maskeleme (e-posta/telefon scrambling).
-
Ayrı sırlar: API anahtarları ortam bazında farklı; ayar enjeksiyonu
.env
ile. -
Konfigürasyon split: Geliştirici modülleri yalnız Dev/Staging’de.
Uygulama: GDPR/KVKK uyumlu maskelenmiş staging; QA ekibi canlı kullanıcı verisini görmeden test yapıyor.
15) Zamanlanmış Görevler (Cron) ve Kuyruklar (Queue)
-
Gerçek cron: Trafiğe bağlı
cron.php
yerine sistem cron kullanın. -
Queue işlemleri: Büyük medya içe aktarımları, e-posta partileri, dış kaynak tüketimi kuyrukla yönetilsin.
-
Yedekleme öncesi/sonrası: Kuyruk boşaltma ve kritik batch işlerini bekletme.
Vaka: Cron çatışması nedeniyle yedek sırasında DB kilitlendi; yedekleme penceresi için cron sessize alındı.
16) İzleme, Alarm ve Raporlama
-
Metrikler: Yedek boyutu, süre, hata oranı, kurtarma denemesi sayısı, son başarılı restore tarihi.
-
Alarm eşikleri: DB dump > X GB veya süre > Y dk ise uyar; offsite replikasyon gecikirse kritik alarm.
-
Rapor: Aylık yönetim özeti + teknik ayrıntı ekleri (hash listeleri, restore süreleri).
Uygulama: “Son başarılı restore tarihi > 30 gün” ise kırmızı alarm; tatbikat unutulmaz.
17) Erişilebilirlik ve Hukuki Uyum (KVKK/GDPR)
-
Saklama politikası: Yedeklerin tutulma süresi ve imha prosedürü.
-
Erişim yetkisi: Yedeklere yalnız yetkili DR ekibi ulaşabilir; erişimler loglanır.
-
Denetim hazırlığı: Dokümante edilmiş süreçler, tatbikat raporları ve kanıt niteliğinde loglar.
Örnek: Tüm yedek erişim logları 1 yıl saklanır; denetimde hızlı kanıt sunulur.
18) Ölçek ve Maliyet Optimizasyonu
-
Sıkıştırma: Gzip/Zstd ile DB dumps; büyük
files
için deduplikasyon. -
Seyrekleştirme: Eski yedeklerin seyrek tutulması (ör. günlük yerine haftalık) + uzun dönem arşiv.
-
Politika bazlı sınıflandırma: Hızlı erişim (hot), standart (warm), arşiv (cold).
Vaka: Görsel ağırlıklı bir portalda Zstd + delta ile aylık depolama maliyeti %28 düştü.
19) Sürüm Yükseltmeleri Sonrası “Geri Dönüş” (Rollback)
-
Atomik dağıtım: Blue/Green veya canary; sürüm etiketleriyle tek komutta geri dönüş.
-
Config ve DB şeması: Şema yükseltmeleri geri alınabilir mi? Gerekirse forward-only plan + yedekten DB dönüş.
-
Runbook: Rollback karar eşiği, kim onaylar, hangi adımlar?
Uygulama: Minor çekirdek güncellemesi sonrası cache layer uyumsuzluk yaptı; 3 dakikada eski sürüme dönüldü.
20) Kullanıcı ve Yetki Yönetimi: Kurtarmada İnsan Faktörü
-
Ayrı roller: “Backup Admin”, “Restore Operator”, “Security Auditor”.
-
Çift kontrol: Kritik silme/kalıcı imha işlemleri için iki kişi onayı.
-
Eğitim: Runbook tatbikatı, Drush/CI kullanımı, güvenlik farkındalığı.
Vaka: Tek kişinin hatalı imhası felakete dönmeden önce çift kontrol sayesinde engellendi.
21) Uçtan Uca Felaket Kurtarma Tatbikatı
-
Tatbikat türleri: Bildirimli (tabletop), kısıtlı kapsamlı (partial), tam kapsamlı (full failover).
-
Süre ölçümü: RTO gerçekçi mi? Darboğaz noktaları nereler?
-
Geliştirme planı: Tatbikat raporunda “iyileştirme backlog”u oluşturun, bir sonraki çeyrekte kapatın.
Örnek: Tam kapsamlı tatbikatla RTO 95 dk’dan 40 dk’ya çekildi; “image styles rebuild” otomasyona alındı.
22) Drupal Özel Riskleri: Config Drift ve Cache Yansımaları
-
Config drift: Prod ve repo’daki config farklılığı kurtarmada sürpriz yaratır;
drush cst
ile kontrol. -
Cache/Metatag tutarsızlığı: Restore sonrası eski cache objeleri; cache flush ve
rebuild
şart. -
Salt ve anahtarlar: CSRF, session, salts – restore sonrası yeniden üretim ve oturum geçersizleştirme.
Vaka: Restore sonrası kullanıcılar oturum sorunları yaşadı; session temizliği ve salt rotasyonu runbook’a eklendi.
23) Test Edilebilirlik için Örnek Komut Akışı (Uygulama)
-
Bakım modu:
drush sset system.maintenance_mode 1
-
Cache temizliği:
drush cr
-
DB restore:
mysql < dump.sql.gz
/psql < dump.sql.gz
-
Files rsync:
rsync -a --delete s3://bucket/files/ sites/default/files/
-
Config import:
drush cim -y
-
Image styles rebuild:
drush images:flush && drush queue:run image_style_scale
-
Cron/kuyruk:
drush cron && drush queue:run *
-
Bakım modunu kapat:
drush sset system.maintenance_mode 0
-
Smoke test: Ana sayfa, login, içerik oluşturma, arama, form gönderimi.
Bu akış, kuruma göre özelleşir; CI/CD ve DR araçlarıyla “tek tuş” haline getirilebilir.
24) Gözden Kaçanlar: E-posta, KİM’lik, DNS ve Sertifikalar
-
SMTP/Email: Restore sonrası SMTP yetkileri ve IP doğrulamaları.
-
Kimlik ve SSO: OIDC/SAML bağlantıları; klayent gizli anahtarları yenileme.
-
DNS ve TLS: DR ortamında TLS sertifikaları, DNS kayıtları ve TTL planı.
Vaka: DR’a çıkışta SMTP IP’si farklıydı; SPF/DKIM geçmedi, transactional mail aksadı. Önceden tanımlı SPF/DKIM/DMARC ile sorun çözüldü.
25) Yedekleme Programı İçin Paydaş Haritası
-
Teknik ekip: DevOps + Backend + Güvenlik.
-
İş birimi: RPO/RTO hedeflerini tanımlar, kritik içerik/kesinti toleransı verir.
-
Yönetim: Bütçe, risk iştahı ve denetim gereksinimleri.
Uygulama: Aylık risk komitesi, yedek-kurtarma KPI’ları (son başarılı restore, ortalama restore süresi, depolama maliyeti).
Sonuç: Drupal’da Kurtarma Gücü, “Yarın”ı Planlamaktır
Drupal sitelerinde teknik yedekleme ve kurtarma; “dosyayı kopyala” yaklaşımının çok ötesinde, hedefleri belirlenmiş (RPO/RTO), otomasyona bağlanmış, test edilmiş ve belgelenmiş bir yönetim pratiğidir. Veritabanı ve dosya sistemi kadar konfigürasyon yönetimi, ortam sırları, üçüncü taraf bağımlılıkları ve CDN/DNS/TLS gibi çevre bileşenleri de kurtarmanın ayrılmaz parçalarıdır. Başarının ölçütü, yalnızca yedeklerin varlığı değil; geri yükleme hızınız, veri kaybı pencereniz ve tatbikatlarla doğrulanmış bir çalışma kitabınızın (runbook) olmasıdır.
Bugün kuracağınız sağlam yedekleme-kurtarma omurgası; sürüm yükseltmeleri, beklenmeyen hata dalgaları ve siber tehditlere karşı işletmenizi dayanıklı kılar. Otomasyon, ölçüm ve düzenli tatbikatla desteklenen bu yaklaşım, yalnızca teknik borcunuzu azaltmakla kalmaz; ekip uyumunu artırır, denetimlere hazır hâle getirir ve en önemlisi kullanıcılarınıza kesintisiz bir deneyim sunar. Drupal’ı uzun soluklu bir yatırım olarak görüyorsanız, yedekleme-kurtarma disiplini bu yatırımın sigortasıdır.