Hosting Tarafında Felaket Kurtarma Provası: cPanel ve VPS Yedeklerini Test Etme Rehberi

Yedek almak çoğu zaman yapılır, ama o yedekten gerçekten geri dönebiliyor musunuz? Pek çok projede kapasite planlama, mimari tasarım veya güvenlik denetimi yaparken gördüğümüz ortak sorun şu: Yedekler var, ama felaket kurtarma provası hiç yapılmamış. Dosyalar nerede, hangi versiyon çalışır durumda, RTO/RPO gerçekten karşılanabiliyor mu, kimse bilmiyor. Bu belirsizlik, özellikle e‑ticaret, SaaS ve kurumsal sitelerde ciddi bir risk.

Bu rehberde, DCHost altyapısında barındırdığınız cPanel hosting ve VPS sunucular için adım adım felaket kurtarma provası nasıl yapılır, pratik şekilde ele alacağız. Amacımız teoriden çok; “Şimdi bir şey bozulsa, hangi adımla nereye tıklayacağınızı” netleştirmek. cPanel tam hesap yedeğinden, VPS dosya sistemi ve veritabanı yedeklerine; farklı senaryoları deneyerek hem kendinize hem ekibinize güven verecek bir prova süreci kurabilirsiniz.

Eğer hâlihazırda yazılı bir planınız yoksa, bu rehberi okurken RTO/RPO hedeflerinizi ve yedekleme politikanızı da gözden geçirmenizi öneririz. Felaket anında panik yapmak yerine, daha önce defalarca prova edilmiş, çalıştığından emin olduğunuz bir felaket kurtarma planı ile ilerlemek hem işinizi hem de uykunuzu korur.

Felaket Kurtarma Provası Neden Şart?

Yedek almak tek başına güvenlik sağlamaz; önemli olan o yedekten ne kadar hızlı ve ne kadar veri kaybıyla geri dönebileceğinizdir. İşte bu noktada devreye felaket kurtarma provası girer. Prova yapmadan, şu soruların cevabı genellikle bilinmez:

• Son çalışan yedeğiniz gerçekten açılıyor mu?
• Geri dönüş süreniz (RTO) işiniz için yeterince kısa mı?
• Ne kadar veri kaybını (RPO) göze almış oluyorsunuz?
• E‑posta, DNS, SSL, cron job gibi yan bileşenler de gerçekten geri geliyor mu?
• Ekibiniz bu adımları biliyor mu, yoksa herkes dokümantasyonu ilk kez felaket anında mı açıyor?

Prova, teoride yazdığınız her şeyi pratikte sınamanız anlamına gelir. Özellikle felaket kurtarma planı yazma rehberimizde de vurguladığımız gibi, plansız ama sık yapılan küçük testler bile, hiç test yapılmamasından çok daha iyidir.

Hosting tarafında felaket kurtarma provasını sistematik hâle getirdiğinizde:

• Gerçek RTO/RPO değerlerinizi görürsünüz.
• Yedekleme politikanızda eksik veya gereksiz pahalı noktaları tespit edersiniz.
• Hangi yedek tipinin (cPanel tam hesap, yalnızca veritabanı, VPS snapshot vs.) hangi senaryo için işe yaradığını netleştirirsiniz.
• Ekibiniz, baskı altında bile adımları otomatikleşmiş şekilde uygulayabilir hâle gelir.

Temel Kavramlar: RPO, RTO, 3‑2‑1 ve Runbook

Prova yapmadan önce aynı dili konuşmak için birkaç kavramı netleştirelim:

RPO (Recovery Point Objective)

En fazla ne kadar veri kaybını kabul edebileceğinizi ifade eder. Örneğin saatlik yedek alıyorsanız, teoride maksimum 1 saatlik veri kaybını göze alıyorsunuz demektir. Prova sırasında, gerçekten hangi tarih/saatteki yedeğe geri dönebildiğinizi ölçerek fiili RPO’nuzu görmeniz gerekir.

RTO (Recovery Time Objective)

Sistemin tamamen durmasından sonra, tekrar ayağa kalkmasının en fazla ne kadar sürebileceğini ifade eder. Örneğin “kritik e‑ticaret sitem için RTO 30 dakika” diyorsanız, felaket kurtarma provasında bu 30 dakikayı tutturup tutturamadığınızı net ölçmelisiniz.

3‑2‑1 Yedekleme Stratejisi

Sağlam bir kurala göre:

• En az 3 kopya veri,
• En az 2 farklı ortamda (ör. yerel disk + uzak object storage),
• En az 1 kopya farklı lokasyonda (off‑site)

tutulmalıdır. Bu yaklaşımı cPanel ve VPS ortamlarında nasıl kurabileceğinizi, 3‑2‑1 yedekleme stratejisi rehberimizde ayrıntılı anlattık. Felaket kurtarma provası, bu stratejinin gerçekten işe yarayıp yaramadığını ölçmenin en iyi yoludur.

Runbook (Adım Adım Uygulama Dökümanı)

Runbook, felaket anında hangi sırayla ne yapılacağını anlatan, adım adım dokümandır. Örneğin:

1. DNS’i bakım sayfasına yönlendir.
2. cPanel’de şu tarihteki tam hesap yedeğini şu test hesabına geri yükle.
3. MySQL veritabanını manuel olarak şu yedekten dön.
4. WordPress config ve .env dosyalarındaki bağlantı ayarlarını güncelle.

Bu rehberde anlatacağımız prova adımlarını, kendi sisteminize göre uyarlayıp runbook olarak saklamanız, felaket anında size büyük hız kazandıracaktır.

Prova Öncesi Hazırlık: Envanter, Kritik Sistemler ve Test Türleri

İyi bir felaket kurtarma provası, “hadi yedeği açmayı deneyelim” diyerek değil, küçük bir planla başlar. Önce şu üç noktayı netleştirmeniz gerekir:

1. Envanter Çıkarma

Hangi sistemleri test edeceğinizi listeleyin:

• cPanel üzerinde çalışan siteler (her biri ayrı hesap mı, addon domain mi?)
• VPS üzerinde çalışan uygulamalar (WordPress, Laravel, Node.js, özel yazılım vs.)
• Veritabanları (MySQL/MariaDB, PostgreSQL vs.)
• DNS, e‑posta, CDN, object storage gibi ek bileşenler

Özellikle addon domain kullanan cPanel hesaplarında izolasyon konusu önemli; bu konuya dair ayrıntıları cPanel’de addon domain mi ayrı hesap mı yazımızda detaylı anlattık.

2. Kritik Sistemleri Belirleme

Her sistem için bir kritik seviye tanımlayın:

• Seviye 1: E‑ticaret, ödeme alan uygulamalar, müşteri paneli gibi gelir üreten kritik sistemler.
• Seviye 2: Kurumsal web sitesi, blog, içerik portalları.
• Seviye 3: Staging, test ortamları, düşük trafikli proje siteleri.

Provalara önce Seviye 3’ten başlayıp, süreç olgunlaştıkça Seviye 1’e çıkmanız mantıklıdır.

3. Test Türlerini Seçme

Genelde üç temel prova tipi yaparız:

• Dosya/Dizin Bazlı Geri Yükleme Testi: Yanlışlıkla silinen bir klasör veya dosya senaryosu.
• Veritabanı Geri Yükleme Testi: Bozulan veya yanlış güncellenen veritabanından geri dönüş.
• Tam Hesap / Tam VPS Geri Yükleme Testi: Sunucu arızası, disk kaybı gibi daha ağır felaket senaryoları.

cPanel tarafında çoğunlukla tam hesap ve veritabanı geri yükleme testleri yapılırken; VPS tarafında dosya sistemi + veritabanı + servis konfigürasyonlarının birlikte ele alındığı tam geri dönüş senaryolarını da mutlaka denemek gerekir.

cPanel Tarafında Felaket Kurtarma Provası

Paylaşımlı hosting veya reseller yapısında en sık karşılaştığımız senaryo cPanel hesabının tamamından veya belirli bileşenlerinden geri dönüş. Burada kritik olan nokta, testleri canlı hesabı bozmadan, mümkünse ayrı bir test hesabında yapmak.

Hangi cPanel Yedek Türlerini Test Etmelisiniz?

Kullandığınız altyapıya göre farklı yedek türleri olabilir, ancak genelde şunları görürüz:

• Tam Hesap Yedeği (Full Account Backup): Home dizini, veritabanları, e‑posta hesapları, DNS zonu dâhil her şeyi içerir.
• Home Dizini Yedeği: Web dosyaları, yapılandırma dosyaları (ör. .htaccess, wp-config.php).
• MySQL Veritabanı Yedeği: Her veritabanı için ayrı .sql veya sıkıştırılmış dosyalar.
• Otomatik Artımlı Yedekler: Genellikle günlük/haftalık alınan, panelde tarih bazlı seçilebilen yedekler.

Felaket kurtarma provasında, en azından şu ikisini mutlaka test etmenizi öneririz:

• Bir tam hesap yedeğini tamamen farklı bir cPanel hesabına geri yüklemek.
• Belirli bir tarihteki veritabanı yedeğini alıp, canlı siteyi bozmadan test ortamına uygulamak.

Adım Adım: Ayrı Bir Hesapta Tam cPanel Yedeği Provası

Bu senaryo, özellikle “şu anki sunucu tamamen gitti” gibi dramatik durumların küçük bir simülasyonu gibidir, ama canlı trafiği etkilemeden.

1. Test için yeni bir cPanel hesabı oluşturun.
   Domain olarak geçici bir subdomain veya tamamen test için açtığınız bir alan adı kullanabilirsiniz.
2. Var olan tam hesap yedeğini bu test hesabına atayın.
   Yedek dosyasını WHM veya paneldeki geri yükleme aracı üzerinden seçerek, test hesabı için restore işlemini başlatın.
3. İşlemin loglarını inceleyin.
   Geri yükleme sırasında kırmızı uyarı veya hata satırları varsa not alın. Eksik sahiplik (ownership) veya izin (permission) sorunları sık görülür.
4. DNS’i değiştirmeden hosts dosyası ile test edin.
   Bilgisayarınızın hosts dosyasına test ederek, gerçek DNS’i bozmadan siteyi sanki canlıymış gibi açabilirsiniz.
5. Uygulama seviyesinde kontrol yapın.
   WordPress, Laravel, PHP uygulamalarınızda login, ürün sayfası, sepet, ödeme testi (sandbox) gibi kritik akışları deneyin.

cPanel tarafında tam yedek ve geri yükleme süreçlerine yeniyseniz, temel adımları görselle birlikte anlattığımız cPanel’de tüm siteyi yedekleme ve geri yükleme rehberimize de göz atmanız faydalı olacaktır.

E‑Posta, DNS, SSL ve Cron İşlerini Doğrulama

Sadece site açılıyor diye prova tamamlanmış sayılmaz. Şu bileşenleri mutlaka kontrol edin:

• E‑posta hesapları: Test hesabında IMAP/POP erişimi, gönderme/alma, spam filtreleri.
• DNS kayıtları: Özellikle MX, SPF/DKIM/DMARC ayarlarının düzgün aktarılıp aktarılmadığı.
• SSL sertifikası: Otomatik yenileme süreçleri (Let’s Encrypt benzeri) test ortamında manuel tetiklenebilir. Ayrıntılı kurulum için Let’s Encrypt ile SSL kurulumu rehberimizi inceleyebilirsiniz.
• Cron job’lar: Özellikle yedek, rapor veya bakım işleri için planladığınız cron görevleri doğru kullanıcı ve dizinde mi çalışıyor, komut yolları bozulmuş mu?

Bu kontrolleri her provada aynı sırayla yapmak için küçük bir check‑list oluşturursanız, hata yapma ihtimalinizi ciddi şekilde düşürürsünüz.

WordPress ve PHP Uygulamaları İçin Özel Kontroller

cPanel tarafında en yaygın iş yükü WordPress olduğu için, felaket kurtarma provasında şu ekstra noktalara bakmanızı öneririz:

• wp-config.php içindeki veritabanı bağlantı bilgileri test ortamına göre güncellenmiş mi?
• Cache eklentileri veya object cache (Redis/Memcached) ayarları test ortamında hata veriyor mu?
• Ödeme ağ geçitleri (WooCommerce gibi) sandbox moduna alınmış mı, canlı ödeme denemesi yapmıyor musunuz?
• Media dosyaları (uploads) eksiksiz mi, eski yazılardaki görseller gerçekten açılıyor mu?

WordPress yedeklerini planlama ve otomatikleştirme konusunda detaylı bir akış isterseniz, WordPress yedekleme stratejileri rehberimiz ile bu yazıdaki felaket kurtarma provasını birlikte okumanız iyi bir çerçeve verecektir.

VPS Tarafında Felaket Kurtarma Provası

VPS ortamında işler biraz daha esnektir; bu da sorumluluğun daha fazla sizde olması anlamına gelir. Yedeklemeyi nasıl ve nereye yaptığınız, geri dönüş senaryolarını da doğrudan etkiler.

VPS Yedek Türleri ve Provada Ne Anlama Gelir?

VPS üzerinde tipik olarak şu yedek türleriyle karşılaşırız:

• Dosya Sistemi Bazlı Yedek: rsync, tar, restic, borg gibi araçlarla alınan, belirli dizinleri kapsayan yedekler.
• Block/Snapshot Yedekleri: VPS diskine ait anlık görüntüler. Genelde hızlı geri yükleme sağlar, ancak boyutu büyük olabilir.
• Veritabanı Özel Yedekleri: mysqldump, XtraBackup, pg_dump, pgBackRest vb. ile alınan yedekler.

Bu yapıları otomatik hâle getirmek için rclone, restic ve cron ile cPanel/VPS yedekleri ve Restic ve Borg ile S3 uyumlu uzak yedekleme yazılarımızda detaylı örnekler paylaştık. Felaket kurtarma provasında ise bu yedeklerden gerçekten ayağa kalkabildiğinizi somut olarak görmek istiyoruz.

Senaryo 1: Tam VPS Geri Dönüş Provası (Yeni VPS Üzerinde)

Bu senaryoda varsayım şu: Mevcut VPS’iniz tamamen kayboldu ve DCHost paneli üzerinden yeni bir VPS açtınız. Şu adımlarla prova yapabilirsiniz:

1. Yeni bir test VPS oluşturun.
   CPU/RAM/disk değerleri üretim ortamına yakın olsun ki geri dönüş süreleri gerçekçi ölçülebilsin.
2. Temel işletim sistemi ve güvenlik ayarlarını yapın.
   SSH erişimi, kullanıcı hesapları, temel güvenlik duvarı; bu aşamada daha önce yazdığımız “Yeni VPS’te ilk 24 saat” ve “VPS sunucu güvenliği” rehberlerindeki adımları referans alabilirsiniz.
3. Yedekleri yeni VPS’e indirin.
   Object storage, uzak SFTP, NFS veya başka bir ortamda tuttuğunuz yedekleri, prova için açtığınız bu VPS’e çekin.
4. Dosya sistemi geri yüklemesini yapın.
   /var/www, /etc/nginx, /etc/php, /home gibi kritik dizinleri yedeğinizin kapsamına göre uygun yerlere geri yazın.
5. Veritabanlarını geri yükleyin.
   MySQL/MariaDB için mysqldump veya XtraBackup, PostgreSQL için pg_dump/pgBackRest yedeklerinizi kullanın. Bu konuda ayrıntılı stratejiler için MySQL/MariaDB yedekleme stratejileri rehberine göz atabilirsiniz.
6. Servisleri sırayla ayağa kaldırın.
   Nginx/Apache, PHP‑FPM, Redis, queue worker’lar, cron job’lar; hepsinin loglarını izleyerek hata olup olmadığını kontrol edin.

Bu prova sırasında, “Yedekleri indirme + geri yükleme + servisleri ayağa kaldırma” adımlarının toplam süresini ölçün; bu, gerçek RTO’nuzun en net göstergesi olacaktır.

Senaryo 2: Dosya/Dizin Bazlı Geri Yükleme Provası

Daha hafif ama pratikte çok sık karşılaşılan senaryo şudur: Bir deploy sırasında yanlış dizini silersiniz veya üretim konfigürasyon dosyasını bozarsınız. Bu durumda tam VPS geri yüklemek yerine, sadece ilgili dizini dönmek çok daha hızlıdır.

Prova için:

1. Test ortamında bilerek bir dosyayı bozun veya silin.
   Örneğin /var/www/project/.env dosyasının bir kopyasını alıp, orijinali silin.
2. Yedeğinizden sadece o dosya veya dizini geri çekin.
   restic/borg/rsync ile tek path geri yükleme senaryosunu deneyin.
3. Uygulamanın tekrar düzgün çalıştığını doğrulayın.
   Loglarda hata kalmadığından, HTTP 500 dönmediğinden emin olun.

Bu küçük prova, gerçek hayatta onlarca deploy sırasında sizi kurtarabilecek kritik bir kas hafızası oluşturur.

Senaryo 3: Veritabanı Geri Dönüşü ve PITR Testi

Özellikle finansal veya sipariş verisi tutan sistemlerde, sadece “son yedeğe” dönmek yeterli olmayabilir. Bazen belirli bir ana kadar ileri veya geri dönmeniz gerekebilir (Point‑in‑Time Recovery ‑ PITR).

Prova için:

1. Test veritabanı oluşturun.
   Üretim veritabanınızın bir kopyasını test isimleriyle yeniden oluşturun.
2. Belirli bir zamana kadar olan WAL/binlog’ları uygulayın.
   Kullandığınız veritabanı çözümüne göre PITR rehberlerini izleyin.
3. Uygulama tarafında veri tutarlılığını kontrol edin.
   Son 1 saatlik siparişlerin görünüp görünmediğini, log kayıtlarıyla karşılaştırın.

Bu tür testler, özellikle SaaS ve e‑ticaret projelerinde, “yanlış toplu güncelleme” veya “hatalı script” gibi senaryolarda hayat kurtarır.

Gerçekçi Prova Senaryoları: Örnekler Üzerinden Gidelim

Örnek 1: WooCommerce Mağazasında Güncelleme Sonrası Çökme

Senaryo: Bir kampanya öncesi WooCommerce ve bazı eklentileri güncellediniz, ancak sepet ve ödeme adımları 500 hatası vermeye başladı. Geri almak için zaman yok, kampanya başlayacak.

Prova akışı şöyle olabilir:

1. Canlı sitede sorun yaşanan anda, en güncel yedeği tespit edin (ör. 2 saat önce alınmış otomatik tam cPanel yedeği).
2. Bu yedeği test cPanel hesabına geri yükleyin, sadece database’i canlı siteden kopyalayın.
3. Staging ortamında sorun gerçekten yedek öncesinde yok mu, doğrulayın.
4. Doğruladıktan sonra, canlı hesabın dosyalarını staging’den geri dönerek veya sadece ilgili plug‑in klasörlerini değiştirmek suretiyle düzeltmeyi uygulayın.

Bu tür senaryolarda, WooCommerce’in veritabanı yapısını ve sorgu davranışını anlamak için WooCommerce için MySQL indeksleme ve sorgu optimizasyonu rehberimize de göz atmanız, hem performans hem de veri tutarlılığı açısından size ekstra içgörü sağlayacaktır.

Örnek 2: Laravel + PostgreSQL VPS’te Disk Arızası

Senaryo: Tek VPS üzerinde çalışan bir Laravel uygulamanız var. PostgreSQL, Redis ve queue worker’lar da aynı sunucuda. Disk I/O hataları almaya başladınız ve en kötüsüne hazırlıklı olmak istiyorsunuz.

Prova akışı:

1. Yeni bir test VPS oluşturun ve üretim sunucusuyla aynı Linux dağıtımını seçin.
2. Güncel dosya sistemi yedeğini (ör. restic/borg) ve PostgreSQL yedeklerini (pg_dump/pgBackRest) bu test VPS’e çekin.
3. Laravel uygulamasını ve tüm servisleri ayağa kaldırın.
4. Uygulama logları, queue job’ları ve cron’ların düzgün çalıştığını doğrulayın.
5. Toplam geçen süreyi kaydedin; bu, gerçek disk arızası anındaki RTO tahmininiz olacaktır.

Bu prova sonucunda “Disk tamamen giderse maksimum 40 dakikada yeni VPS’ten ayağa kalkabiliyoruz” gibi somut bir cümle kurabiliyorsanız, doğru yoldasınız demektir.

Sonuçları Dokümante Etmek ve İyileştirmek

Her felaket kurtarma provası, aslında küçük bir deneytir. Deneyin değerli olması için sonuçları mutlaka kaydetmeniz gerekir. Önerdiğimiz temel metrikler:

• Başlangıç ve bitiş saatleri: Gerçek RTO ölçümü için.
• Kullanılan yedek zamanı: Gerçek RPO ölçümü için.
• Karşılaşılan hatalar ve çözümleri: Bir sonraki provada veya gerçek felakette aynı tuzağa tekrar düşmemek için.
• İyileştirme fikirleri: Örneğin bazı komutları script’e dökmek, belirli dizinleri ayrı yedeklemek, loglama seviyesini artırmak gibi.

Bu dokümantasyonu, kurum içi wiki’nizde veya bir ticket sistemi üzerinde düzenli olarak saklamanızı tavsiye ederiz. Böylece hem ekip içi bilgi birikimi oluşur, hem de denetim/uyum süreçlerinde elinizde somut kanıt olur.

Daha stratejik bir açıdan bakmak isterseniz, felaket kurtarma planını baştan sona nasıl kurgulamanız gerektiğini, felaket kurtarma planı yazma rehberimizde ayrıntılı ve uygulamaya dönük örneklerle anlattık. Bu yazıdaki teknik prova adımlarını, oradaki stratejik yaklaşımla birleştirdiğinizde, gerçekten sağlam bir DR çerçevesine sahip olursunuz.

DCHost Üzerinde Felaket Kurtarma Provasını Nasıl Kurabilirsiniz?

Bu rehberi yazarken aklımızda hep şu vardı: DCHost üzerinde çalışan projeleriniz için, kâğıt üstünde kalmayan, gerçekten uygulanabilir bir felaket kurtarma rutini oluşturmak. Özetle şu yaklaşımı öneriyoruz:

• cPanel hesaplarınız için, düzenli otomatik yedeklerin yanı sıra, kritik dönemler (büyük güncelleme, kampanya öncesi) öncesi manuel ek yedekler planlayın.
• VPS tarafında, yerel disk yedeklerinin yanında mutlaka uzak bir S3 uyumlu object storage üzerinde ek kopya tutun. Bunu otomatikleştirmek için rclone/restic ile object storage’a otomatik yedek alma rehberimiz size pratik bir rehber sunar.
• WordPress, WooCommerce ve benzeri yoğun kullanılan projeleriniz için staging ortamı ve düzenli yedek testlerini ihmal etmeyin; burada da WordPress yedekleme stratejileri yazısındaki önerileri bu rehberle birlikte uygulayabilirsiniz.
• Yılda en az 1‑2 kez, kritik projeleriniz için tam geri dönüş provası yapın ve sonuçlarını runbook’larınıza işleyin.

Eğer DCHost altyapısında cPanel, VPS, dedicated veya colocation hizmetleriniz varsa ve bu rehberi kendi ortamınıza uyarlamak istiyorsanız, yedekleme ve felaket kurtarma senaryolarınızı birlikte gözden geçirebiliriz. Hangi yedek türlerinin hangi senaryo için daha uygun olduğu, RTO/RPO hedefleriniz ve bütçe dengenizle birlikte ele alındığında, gerçekten içinizi rahatlatan bir felaket kurtarma stratejisi kurmak mümkün.

Sonuç olarak: Felaketin ne zaman geleceğini bilemezsiniz, ama geldiğinde ne yapacağınızı önceden prova ederek rahat uyuyabilirsiniz. cPanel ve VPS yedeklerinden düzenli geri dönüş testleri yapmak, bunun en somut ve uygulanabilir adımı. Bugün küçük bir testle başlayın; bir sonraki büyük sorunda, bu çabanın ne kadar değerli olduğunu çok net göreceksiniz.