Bir üniversite web sitesinin saatlerce erişilemez olması yalnızca teknik bir aksaklık değildir; başvuru süreçlerini, öğrenci portallarını, ödeme akışlarını ve kurumun itibarını doğrudan etkiler. Drupal güçlü ve güvenli bir içerik yönetim sistemi olmasına rağmen, hiçbir altyapı insan hatasına, donanım arızasına veya siber saldırıya karşı tamamen bağışık değildir. Bu nedenle yedekleme ve felaket kurtarma (Disaster Recovery), Drupal tabanlı kurumsal bir web sitesinin olmazsa olmaz bileşenidir.
Bu rehberde Drupal yedeklemenin neyi kapsadığını, hangi araçlarla yapıldığını, RTO ve RPO gibi temel kavramları, üniversiteler için kritik DR senaryolarını ve Drupal4edu yaklaşımıyla nasıl uçtan uca bir koruma planı kurulabileceğini açıklıyoruz.
Drupal Yedekleme Nedir ve Neden Kritiktir?
Drupal yedekleme, sitenizin çalışmaya devam edebilmesi için gerekli olan tüm bileşenlerin belirli aralıklarla güvenli bir kopyasının alınması işlemidir. Tek başına dosya kopyalamak ya da yalnızca veritabanı çıktısı almak eksik bir yedek üretir. Tam bir Drupal yedeği üç temel katmandan oluşur.
- Veritabanı: Tüm içerik, kullanıcı bilgileri, yapılandırma ve oturum verileri burada tutulur. Veritabanı dökümü olmadan içeriğinizi geri getiremezsiniz.
- Kullanıcı dosyaları: Görseller, PDF'ler, ders materyalleri, akademisyen fotoğrafları gibi yüklenen tüm medya. Bunlar genellikle sites/default/files altında saklanır.
- Kod ve yapılandırma: Drupal çekirdeği, modüller, özel kodlar, tema dosyaları ve dışa aktarılmış yapılandırma (config sync) dosyaları.
Yedekleme yalnızca felaket anında değil, planlı operasyonlarda da kritik bir güvenlik ağı işlevi görür. Drupal çekirdek güncellemesinden önce, yeni bir modül kurulurken, izin yapısı veya görüntüleme yapılandırmasında toplu değişiklik yapılırken ya da büyük bir içerik göçü öncesinde mutlaka yedek alınması önerilir; çünkü iyi test edilmiş güncellemeler bile özel kod barındıran üretim ortamında beklenmedik davranabilir.
Neden bu kadar önemli?
Veri kaybı genellikle siber saldırı değil; insan hatası, başarısız güncelleme, depolama bozulması veya hosting sağlayıcı kaynaklı kesintiyle başlar. Bu yüzden "yedeğim var" yetmez; yedeğin nerede, ne sıklıkla, nasıl test edildiği belirleyici olur.
Yedekleme ile Felaket Kurtarma Aynı Şey Değildir
Bu iki kavram sıkça birbirinin yerine kullanılır, fakat ayrı şeylerdir. Yedekleme, verinin bir kopyasını oluşturma eylemidir. Felaket kurtarma planı (Disaster Recovery Plan) ise bir kesinti yaşandığında siteyi belirli bir hizmet seviyesinde, belirli bir süre içinde yeniden ayağa kaldırmak için izlenen prosedürlerin tamamıdır.
Bir başka deyişle yedekleme bir dosyadır; felaket kurtarma bir planın yazılı halidir. Plan içinde kimin neyi ne zaman yapacağı, yedeklerin nerede saklandığı, geri yükleme süresinin ne kadar olduğu ve kabul edilebilir veri kaybı seviyesinin ne olduğu açıkça tanımlanır.
RTO ve RPO: Felaket Kurtarmanın İki Temel Metriği
Profesyonel bir DR planının iki kritik parametresi vardır.
- RTO (Recovery Time Objective): Sistemin tekrar çalışır hale gelmesi için kabul edilebilir maksimum süre. Örneğin RTO 2 saat ise, kesintiden 2 saat içinde site yeniden açık olmalıdır.
- RPO (Recovery Point Objective): Kabul edilebilir maksimum veri kaybı süresi. RPO 1 saat ise, geri yükleme sonrası en fazla 1 saatlik veri kayıp kabul edilir. Bu da yedeklemenin en az saatte bir alınması gerektiğini söyler.
Üniversite siteleri için bu metrikler kayıt dönemleri, sınav sonuç ilanları veya akreditasyon süreçleri yaklaştıkça çok daha sıkı tanımlanmalıdır. Örneğin başvuru günü çöken bir site, hem aday öğrenciyi hem de kurumun itibarını birden kaybettirir.
3-2-1 Yedekleme Kuralı: Endüstri Standardı
Yedekleme dünyasında 3-2-1 kuralı altın standart kabul edilir.
- Verinin en az 3 kopyası olmalıdır (1 ana, 2 yedek).
- Bu kopyalar en az 2 farklı ortam/cihazda saklanmalıdır.
- En az 1 kopya site dışı (offsite) bir lokasyonda tutulmalıdır.
Drupal için bu kural pratikte şöyle uygulanır: birinci kopya sitenin çalıştığı üretim sunucusunda, ikinci kopya bağımsız bir yedek sunucusunda veya bulut depolama servisinde (Amazon S3, Azure Blob gibi), üçüncü kopya ise tamamen farklı bir lokasyonda tutulur. Aynı sunucuda saklanan yedek, sunucu çöktüğünde yedek olmaktan çıkar.
Drupal Sitelerinde Yedekleme Yöntemleri
Drupal ekosisteminde yedek almak için birkaç farklı yöntem vardır. Hangisinin seçileceği sitenin büyüklüğüne, trafiğine, ekibin teknik kapasitesine ve hosting altyapısına göre değişir.
Backup and Migrate Modülü
Drupal'ın en bilinen yedekleme modülüdür. Veritabanını, dosyaları ve kodu yedekleme, zamanlanmış yedek tanımlama, gzip/bzip/zip sıkıştırma ve isteğe bağlı şifreleme gibi özellikler sunar. Küçük ve orta ölçekli siteler için arayüzü kullanışlıdır; ancak yedekleri tamamen üretim sunucusunda tuttuğu için tek başına bir felaket kurtarma çözümü olarak yeterli değildir. Sunucu çökerse yedeklere de erişilemez.
Drush ile Komut Satırından Yedekleme
Drush, Drupal'ın komut satırı aracıdır. Veritabanı dökümü için drush sql-dump, kod ve veritabanını birlikte arşivlemek için drush archive-dump gibi komutlar sunar. Sunucu üzerinde cron ile birleştirildiğinde otomatik ve programlanabilir bir yedekleme akışı kurulabilir. Geliştirici dostudur ve büyük sitelerde modül tabanlı çözümlerden daha güvenilirdir.
Sunucu Seviyesi (Snapshot) Yedekleri
Hosting sağlayıcının veya bulut platformunun sunduğu disk-snapshot tabanlı yedekleme yöntemidir. Pantheon, Acquia ve Platform.sh gibi yönetilen Drupal platformları snapshot tabanlı otomatik yedek sunar. Avantajı tüm sunucunun anlık görüntüsünü almasıdır. Dezavantajı, bazı sağlayıcıların bu yedekleri yalnızca kendi iç felaket kurtarma süreçleri için kullanması, yani site sahibine ad-hoc geri yükleme imkânı vermemesidir. Sözleşme öncesi mutlaka kontrol edilmesi gereken bir noktadır.
Restic Backup Modülü
Daha modern bir yaklaşım sunan Restic Backup modülü, özellikle yüklenen dosyaların yedeklenmesinde verimlidir. Artımlı (incremental) yedekleme ve veri tekilleştirme (deduplication) sayesinde depolama maliyetini düşürür. SFTP veya S3 gibi farklı hedeflere yedek alabilir. Büyük medya kütüphanesine sahip üniversite sitelerinde kod için Git, veritabanı için Retention Database Backup ve dosyalar için Restic kombinasyonu kapsamlı bir koruma sağlar.
Yedekleme Sıklığı ve Saklama Politikası
Yedekleme sıklığı sitenin güncellenme hızına göre belirlenir. Düzenli içerik üreten, çok sayıda kullanıcının aynı anda işlem yaptığı bir üniversite portalı için pratik bir saklama politikası şöyle olabilir.
| Yedek Tipi | Sıklık | Saklama Süresi |
| Günlük | Her gün | Son 7 gün |
| Haftalık | Her hafta | Son 4 hafta |
| Aylık | Ayda bir | Son 6–12 ay |
| Olay tabanlı | Güncelleme/migration öncesi | İlgili görev tamamlanana kadar |
Bu politika sitenin değişim hızına ve veri hassasiyetine göre sıkılaştırılabilir. Örneğin sınav sonuçlarının ilan edildiği gün veya kayıt döneminde yedekleme aralığını saatlere indirmek mantıklıdır.
Üniversiteler İçin Drupal Yedekleme: Farklı Olan Ne?
Bir kurumsal site ile bir üniversite sitesinin yedekleme ihtiyaçları benzer görünse de uygulama detayında ciddi farklar vardır.
- Çoklu site (multisite) mimarisi: Üniversiteler genellikle ana site, fakülteler, enstitüler, kütüphane, araştırma merkezleri için onlarca alt site barındırır. Her birinin ayrı yedek politikası gerekir ama ortak bir DR çatısı altında yönetilmelidir.
- LMS entegrasyonu: Moodle, Canvas veya kurumsal LMS'lerle entegre çalışan Drupal sitelerinde, yedeğin entegrasyon parametrelerini ve cache'lerini tutarlı şekilde yakalaması gerekir.
- Kişisel veri ve mevzuat: Öğrenci verisi KVKK kapsamındadır. AB'deki kampüsler için GDPR, ABD'deki çözümlerde FERPA dikkate alınır. Yedeklerin de şifrelenmiş ve erişim kontrollü olması zorunludur.
- Yoğun trafik pencereleri: Kayıt dönemi, başvuru günü, sınav sonuç ilanı gibi dönemlerde RTO/RPO eşikleri kısaltılır. Kesintinin maliyeti normal günlere göre kat kat yüksektir.
- Akreditasyon ve denetim: YÖK, ABET, AACSB gibi denetimler için site içerik geçmişinin korunması ve geri çağrılabilir olması gerekebilir. Uzun süreli arşiv yedekleri bu noktada devreye girer.
Adım Adım Drupal Felaket Kurtarma Planı
Yedek tek başına bir felaket kurtarma planı değildir. Aşağıdaki adımlar, üniversite ölçeğinde uygulanabilir bir DR çerçevesi sunar.
- Kritik varlıkları envanterleyin. Hangi sistemler (ana site, başvuru portalı, kütüphane, mezunlar) hangi öncelik seviyesinde olacak, listeleyin.
- Her sistem için RTO ve RPO değerlerini belirleyin. Bu, yedekleme sıklığını ve teknolojiyi doğrudan belirler.
- 3-2-1 prensibine göre yedekleme mimarisini kurun: üretim, ayrı sunucu/bulut, offsite.
- Yedekleri şifreleyin. KVKK ve GDPR için bu bir uyum gereksinimidir; ayrıca yedeklerin sızdırılması büyük bir risktir.
- Geri yükleme prosedürünü yazılı hâle getirin. Kim, ne, ne sırayla yapacak? Sorumlu kişi tatildeyse yedeği kim devralacak?
- DR planını düzenli aralıklarla test edin. Sadece kâğıt üzerinde duran bir plan, kriz anında çoğunlukla işe yaramaz.
- Versiyon kontrolüyle entegre çalışın. Kodu Git ile yönetin; yedek sadece veritabanı ve dosyaları kapsasın.
- İletişim planı hazırlayın. Kesinti anında öğrencilere, akademisyenlere ve basına nasıl bilgi verileceğini önceden tasarlayın.
Yedekleri Test Etmeden Onlara Güvenmeyin
Sektördeki en pahalı dersi tek cümleyle özetlemek gerekirse: test edilmemiş bir yedek, yedek değildir. Pek çok ekibin yıllarca yedek aldığı, fakat ilk geri yükleme denemesinde yedeğin bozuk, eksik veya yanlış versiyonda olduğunu fark ettiği vakalar yaşanmıştır.
Bunun için yapılması gerekenler basittir. Belirli bir takvimle (örneğin üç ayda bir) yedek dosyalardan staging ortamına gerçek bir geri yükleme yapın. Geri yüklenen sitede içerik bütünlüğü, kullanıcı oturumları, yapılandırma ayarları ve entegrasyonlar tek tek kontrol edilmelidir. Sonuçlar raporlanmalı, sorunlar düzeltilmeli ve test geçmişi belgelendirilmelidir.
Sık Yapılan Yedekleme Hataları
- Yedeği aynı sunucuda tutmak: Sunucu çöktüğünde yedek de erişilemez hâle gelir.
- Yalnızca veritabanını yedeklemek: Kod ve kullanıcı dosyaları olmadan site geri gelmez.
- Yedekleri şifrelememek: Sızdırılan bir yedek, üretim sızıntısıyla eşdeğer hasarı oluşturur.
- Geri yükleme prosedürünü dokümante etmemek: Kriz anında doğaçlama yapmak hata riskini artırır.
- Yedekleri test etmemek: Bozuk yedek, hiç yedek almamaktan daha tehlikeli olabilir.
- Modül seçimini ihmal etmek: Modül tabanlı yedek bazı kritik senaryolarda yetersiz kalır; sunucu seviyesi yedekleme ile kombine edilmelidir.