Ankara
0 (312) 276 75 93
info@billgatesweb.com

Drupal Web Sitesinde Teknik Yedekleme ve Kurtarma

Web Danışmanlık Hizmeti, Seo Hizmeti Al, Mobile Uygulama Yaptır, Back Link Satın Al, Blog Yazdırmak İstiyorum, Makale YAZDIRMA siteleri, Parayla makale YAZDIRMA, Seo makale fiyatları, Sayfa başı yazı yazma ücreti, İngilizce makale yazdırma, Akademik makale YAZDIRMA, Makale Fiyatları 2022, Makale yazma, Blog Yazdırma, Akademik Danışmanlık, Tercüme Danışmanlık & 0 (312) 276 75 93

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 ile config/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) ve drush cim (import) ile config/sync klasörü tamamen versiyonlanır.

  • Ortam ayrımı: Prod/Staging/Dev için farklı settings.php ve config_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)

  1. Bakım modu: drush sset system.maintenance_mode 1

  2. Cache temizliği: drush cr

  3. DB restore: mysql < dump.sql.gz / psql < dump.sql.gz

  4. Files rsync: rsync -a --delete s3://bucket/files/ sites/default/files/

  5. Config import: drush cim -y

  6. Image styles rebuild: drush images:flush && drush queue:run image_style_scale

  7. Cron/kuyruk: drush cron && drush queue:run *

  8. Bakım modunu kapat: drush sset system.maintenance_mode 0

  9. 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.

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!

 

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir