- Katılım
- 21 May 2023
- Mesajlar
- 505
- Tepki
- 17
- Puan
- 18
Sitenizin çöktüğü an panele giriyor, "Yedekler" bölümünü açıyorsunuz. Liste yeşil: her gece otomatik bir yedek alınmış görünüyor. Ama o dosyayı daha önce hiç geri yüklemediyseniz, yeşil işaret yalnızca "dosya oluşturuldu" der; "bu dosyadan site eski haline döner" demez.
Kısa cevap: yedeğin var olması, geri dönüşün çalıştığının kanıtı değildir. Bunu öğrenmenin tek güvenli yolu, sorun çıkmadan önce canlı siteye dokunmadan bir geri yükleme provası yapmaktır.
Bir yedekleme betiği "başarılı" logu bırakabilir, dosya boyutu sıfır olmayabilir, iş kesintisiz bitebilir. Bunların hiçbiri o dosyanın açılıp bir siteyi gerçekten ayağa kaldırdığını göstermez. NIST'in acil durum planlama rehberi SP 800-34 Rev. 1 burada iki kavram tanımlıyor: Kurtarma Süresi Hedefi (RTO), bir sistem kaynağının diğer süreçleri kabul edilemez şekilde etkilemeden kapalı kalabileceği azami süredir; Kurtarma Noktası Hedefi (RPO) ise kesintiden önce, elinizdeki en güncel yedek kopyası kullanıldığında verinin geri getirilebileceği andır. Sade söylersek: RTO "ne kadar sürede döneceğiz", RPO "hangi ana kadar olan veriyi kurtarabileceğiz" sorusunun cevabıdır. Bu iki soruyu önceden yanıtlamazsanız, cevabı tam da en kötü anda, deneme yapacak sakinliğiniz kalmamışken öğrenirsiniz.
Varsayılan yedek profili "her şeyi" kapsadığını düşündürür ama resmî belgelerde bile kapsam bir seçimdir. cPanel/WHM'nin resmî yedekleme yapılandırması belgesine göre sistem yöneticisi "Kullanıcı Hesaplarını Yedekle", "SQL Veritabanlarını Yedekle" ve "/etc dizinindeki Sistem Dosyalarını Yedekle" seçeneklerini ayrı ayrı açıp kapatabiliyor; PostgreSQL veritabanları varsayılan olarak yedeklenmiyor ve ayrı yapılandırma istiyor, DNS bilgisi ise yerel ya da uzak kaynaktan seçilerek ekleniyor. Kullanıcı tarafındaki Backup Wizard belgesi de tam yedeğin (.tar.gz) cPanel arayüzünden değil yalnızca WHM üzerinden geri yüklenebildiğini, günlük kullanımda ana dizin, veritabanları ve e-posta yönlendirme/filtre kurallarının ayrı "kısmi yedek" dosyaları olarak indirildiğini belirtiyor. Sizin panelinizde hangi kutucuklar işaretli, ek bir veritabanı motoru var mı, e-posta kutularının kendisi mi yoksa yalnızca kuralları mı dahil — bunu varsaymak yerine yönetim panelinizin kendi yedekleme ayarları sayfasından tek tek görün.
CISA, FBI ve MS-ISAC'ın ortak yayınladığı #StopRansomware Rehberi, yedeklerin çevrimdışı ve şifreli tutulmasını, kullanılabilirliğinin ve bütünlüğünün bir felaket kurtarma senaryosunda düzenli olarak test edilmesini öneriyor; çünkü saldırganlar hedef ortamdaki kimlik bilgilerini ele geçirip yedekleme çözümüne erişmeye çalışıyor, bulduğu erişilebilir yedekleri siliyor veya şifreliyor. Aynı rehber, otomatik bulut-bulut yedeklerin de tek başına yeterli olmayabileceğini söylüyor: yerel dosyalar şifrelenirse bu değişiklik buluta senkronize olup sağlam veriyi ezebiliyor. Hosting bağlamına çevirirsek, yedek dosyası aynı hesabın içinde, aynı sunucuda duruyorsa; sunucuyu vuran her olay (disk arızası, hesabın askıya alınması, saldırı) yedeği de birlikte götürür. En az bir kopyanın sunucudan bağımsız bir yerde durması bu yüzden ayrı bir adım, "aynı yedeğin bir kopyası" değil.
NIST SP 800-34, bir acil durum planı testinin "alternatif bir platformda yedek medyadan sistem kurtarma" adımını içermesi gerektiğini ve test planının açık başarı ölçütleriyle tanımlanmasını öneriyor. Pratikte bu, provayı canlı alan adında değil; ayrı bir alt alan adında, ayrı bir test hesabında veya yerel bilgisayarınızda kurmak demek. cPanel'in kendi belgesi bile tam yedeğin geri yüklenmesini farklı bir araca (WHM) bağlıyor; yani hangi aracın hangi geri yükleme türünü desteklediğini panelin kendi belgesinden görmeden "nasılsa geri yüklerim" dememek gerekiyor. Amaç, gerçek dosyayı gerçek bir ortamda açıp çalıştırmak — panelde gördüğünüz "yedek indirildi" mesajına güvenmemek.
NIST'in test rehberliği, bir kurtarma testinin nitel değil ölçülebilir ölçütlerle değerlendirilmesi gerektiğini vurguluyor. Prova ortamında en az şunlar kontrol edilmeden sonuç "başarılı" sayılmamalı:
Bu adımların tamamlanma süresi sizin gerçek RTO'nuzu, geri gelen en güncel kaydın tarihi ile olay anı arasındaki fark ise gerçek RPO'nuzu gösterir — panelin vaat ettiği rakamları değil.
Provanın tarihini, hangi ortamda yapıldığını, süresini ve karşılaşılan eksik listesini bir yerde yazılı tutun ki bir sonraki prova bununla karşılaştırılabilsin. Sunucu ve alan adı tarafındaki genel kontrolleri hosting ve domain rehberimizle, altyapıyı sıfırdan kurarken izlenecek sırayı ise hosting/CDN/SSL başlangıç rotamızla tamamlayabilirsiniz. Yedek zaten bir ihlalden sonra devreye giriyorsa, geri yüklemeden önce hangi dosyaların temiz olduğunu belirlemek ayrı bir iştir; bu adımları site virüsü temizliği yazımızda ayrıntılı anlattık — bu yazı yalnızca yedeğin sınanmasına odaklanıyor.
Yedek dosyasının var olması ile sitenizin o dosyadan gerçekten ayağa kalkması iki ayrı şeydir. Kapsamı panelinizin kendi belgesinden doğrulayın, en az bir kopyayı sunucudan bağımsız tutun, provayı canlıya dokunmadan ayrı bir ortamda yapın ve "geri döndü" demeden önce kabul ölçütlerinizi önceden yazın. Son geri yükleme provanızda beklemediğiniz hangi eksik çıktı?
Güncelleme: 21 Ağustos 2026. CISA/FBI/MS-ISAC'ın #StopRansomware Rehberi, NIST SP 800-34 Rev. 1 ve cPanel/WHM'nin resmî yedekleme belgeleri kontrol edildi.
Kısa cevap: yedeğin var olması, geri dönüşün çalıştığının kanıtı değildir. Bunu öğrenmenin tek güvenli yolu, sorun çıkmadan önce canlı siteye dokunmadan bir geri yükleme provası yapmaktır.
En kötü an, geri yüklemeyi ilk kez sorun sırasında denemektir
Bir yedekleme betiği "başarılı" logu bırakabilir, dosya boyutu sıfır olmayabilir, iş kesintisiz bitebilir. Bunların hiçbiri o dosyanın açılıp bir siteyi gerçekten ayağa kaldırdığını göstermez. NIST'in acil durum planlama rehberi SP 800-34 Rev. 1 burada iki kavram tanımlıyor: Kurtarma Süresi Hedefi (RTO), bir sistem kaynağının diğer süreçleri kabul edilemez şekilde etkilemeden kapalı kalabileceği azami süredir; Kurtarma Noktası Hedefi (RPO) ise kesintiden önce, elinizdeki en güncel yedek kopyası kullanıldığında verinin geri getirilebileceği andır. Sade söylersek: RTO "ne kadar sürede döneceğiz", RPO "hangi ana kadar olan veriyi kurtarabileceğiz" sorusunun cevabıdır. Bu iki soruyu önceden yanıtlamazsanız, cevabı tam da en kötü anda, deneme yapacak sakinliğiniz kalmamışken öğrenirsiniz.
Sınama neyi kanıtlar' Alıntı:
Yedeğin kapsamını varsaymayın, panelden doğrulayın
Varsayılan yedek profili "her şeyi" kapsadığını düşündürür ama resmî belgelerde bile kapsam bir seçimdir. cPanel/WHM'nin resmî yedekleme yapılandırması belgesine göre sistem yöneticisi "Kullanıcı Hesaplarını Yedekle", "SQL Veritabanlarını Yedekle" ve "/etc dizinindeki Sistem Dosyalarını Yedekle" seçeneklerini ayrı ayrı açıp kapatabiliyor; PostgreSQL veritabanları varsayılan olarak yedeklenmiyor ve ayrı yapılandırma istiyor, DNS bilgisi ise yerel ya da uzak kaynaktan seçilerek ekleniyor. Kullanıcı tarafındaki Backup Wizard belgesi de tam yedeğin (.tar.gz) cPanel arayüzünden değil yalnızca WHM üzerinden geri yüklenebildiğini, günlük kullanımda ana dizin, veritabanları ve e-posta yönlendirme/filtre kurallarının ayrı "kısmi yedek" dosyaları olarak indirildiğini belirtiyor. Sizin panelinizde hangi kutucuklar işaretli, ek bir veritabanı motoru var mı, e-posta kutularının kendisi mi yoksa yalnızca kuralları mı dahil — bunu varsaymak yerine yönetim panelinizin kendi yedekleme ayarları sayfasından tek tek görün.
Aynı sunucudaki yedek, sunucuyla birlikte gider
CISA, FBI ve MS-ISAC'ın ortak yayınladığı #StopRansomware Rehberi, yedeklerin çevrimdışı ve şifreli tutulmasını, kullanılabilirliğinin ve bütünlüğünün bir felaket kurtarma senaryosunda düzenli olarak test edilmesini öneriyor; çünkü saldırganlar hedef ortamdaki kimlik bilgilerini ele geçirip yedekleme çözümüne erişmeye çalışıyor, bulduğu erişilebilir yedekleri siliyor veya şifreliyor. Aynı rehber, otomatik bulut-bulut yedeklerin de tek başına yeterli olmayabileceğini söylüyor: yerel dosyalar şifrelenirse bu değişiklik buluta senkronize olup sağlam veriyi ezebiliyor. Hosting bağlamına çevirirsek, yedek dosyası aynı hesabın içinde, aynı sunucuda duruyorsa; sunucuyu vuran her olay (disk arızası, hesabın askıya alınması, saldırı) yedeği de birlikte götürür. En az bir kopyanın sunucudan bağımsız bir yerde durması bu yüzden ayrı bir adım, "aynı yedeğin bir kopyası" değil.
Provayı canlıya dokunmadan ayrı bir ortamda kurun
NIST SP 800-34, bir acil durum planı testinin "alternatif bir platformda yedek medyadan sistem kurtarma" adımını içermesi gerektiğini ve test planının açık başarı ölçütleriyle tanımlanmasını öneriyor. Pratikte bu, provayı canlı alan adında değil; ayrı bir alt alan adında, ayrı bir test hesabında veya yerel bilgisayarınızda kurmak demek. cPanel'in kendi belgesi bile tam yedeğin geri yüklenmesini farklı bir araca (WHM) bağlıyor; yani hangi aracın hangi geri yükleme türünü desteklediğini panelin kendi belgesinden görmeden "nasılsa geri yüklerim" dememek gerekiyor. Amaç, gerçek dosyayı gerçek bir ortamda açıp çalıştırmak — panelde gördüğünüz "yedek indirildi" mesajına güvenmemek.
Beş kontrol geçmeden "geri döndü" denmez
NIST'in test rehberliği, bir kurtarma testinin nitel değil ölçülebilir ölçütlerle değerlendirilmesi gerektiğini vurguluyor. Prova ortamında en az şunlar kontrol edilmeden sonuç "başarılı" sayılmamalı:
- Yönetici ve kullanıcı girişleri çalışıyor mu?
- Bir form (iletişim, kayıt) uçtan uca gönderilip kayıt oluşturuyor mu?
- Varsa ödeme veya sipariş akışı test modunda tamamlanabiliyor mu?
- Son 24 saatlik içerik ve kayıtlar (yorum, sipariş, log) geri gelen veride var mı, yoksa RPO'nuz o kadar mı geniş?
- Dış bağlantılar (e-posta gönderimi, API anahtarları, harici depolama) yeni ortamda hâlâ doğru mu?
Bu adımların tamamlanma süresi sizin gerçek RTO'nuzu, geri gelen en güncel kaydın tarihi ile olay anı arasındaki fark ise gerçek RPO'nuzu gösterir — panelin vaat ettiği rakamları değil.
Provayı tek seferlik iş olarak görmeyin
Provanın tarihini, hangi ortamda yapıldığını, süresini ve karşılaşılan eksik listesini bir yerde yazılı tutun ki bir sonraki prova bununla karşılaştırılabilsin. Sunucu ve alan adı tarafındaki genel kontrolleri hosting ve domain rehberimizle, altyapıyı sıfırdan kurarken izlenecek sırayı ise hosting/CDN/SSL başlangıç rotamızla tamamlayabilirsiniz. Yedek zaten bir ihlalden sonra devreye giriyorsa, geri yüklemeden önce hangi dosyaların temiz olduğunu belirlemek ayrı bir iştir; bu adımları site virüsü temizliği yazımızda ayrıntılı anlattık — bu yazı yalnızca yedeğin sınanmasına odaklanıyor.
Özetle
Yedek dosyasının var olması ile sitenizin o dosyadan gerçekten ayağa kalkması iki ayrı şeydir. Kapsamı panelinizin kendi belgesinden doğrulayın, en az bir kopyayı sunucudan bağımsız tutun, provayı canlıya dokunmadan ayrı bir ortamda yapın ve "geri döndü" demeden önce kabul ölçütlerinizi önceden yazın. Son geri yükleme provanızda beklemediğiniz hangi eksik çıktı?
Güncelleme: 21 Ağustos 2026. CISA/FBI/MS-ISAC'ın #StopRansomware Rehberi, NIST SP 800-34 Rev. 1 ve cPanel/WHM'nin resmî yedekleme belgeleri kontrol edildi.
Dijital Dünyanıza Yön Veren Pusula
