Ana içeriğe geç

Güvenilir Kurtarma için Sunucu Yedekleme Kontrol Listesi

· 5 dakikalık okuma
Customer Care Engineer

25 Eylül 2026 tarihinde yayımlandı

Güvenilir Kurtarma için Sunucu Yedekleme Kontrol Listesi

Hiç geri yüklenmemiş bir yedekleme koruma değildir. Başka bir yerde duran umut verici bir dosyadır. Bu sunucu yedekleme kontrol listesi; web siteleri, veritabanları, e-posta, kullanıcı dosyaları, sunucu ayarları ve bunları geri getirmek için gereken erişim gibi işletmenizin faaliyetlerini gerçekten sürdüren unsurlar için bir kurtarma planı oluşturmanıza yardımcı olur.

Amaç, mümkün olan en büyük arşivi oluşturmak değildir. Amaç, doğru hizmetin doğru sürümünü müşterilerinizin tolere edebileceği bir süre içinde kurtarmaktır. Küçük bir tanıtım sitesi ile yoğun kullanılan bir çevrim içi mağazanın aynı zamanlamaya, depolama tasarımına veya kurtarma hedefine ihtiyacı yoktur. İyi bir yedekleme planlaması burada başlar.

Depolamayla Değil, Kurtarmayla Başlayın​

Bir yedekleme hedefi seçmeden veya zamanlama ayarlamadan önce, bir arızanın maliyetine karar verin. İki pratik soru sorun: Ne kadar güncel veriyi kaybetmeyi göze alabilirsiniz ve hizmet ne kadar süre kullanılamaz durumda kalabilir?

İlk yanıtınız, genellikle RPO olarak adlandırılan kurtarma noktası hedefinizdir. Mağazanız gün boyunca sipariş alıyorsa günlük veritabanı yedeklemesi, işlemlerin tamamında bir günlük kayıp anlamına gelebilir. İkincisi ise kurtarma süresi hedefiniz veya RTO'dur. Bir sunucuyu geri yüklemek altı saat sürüyor ancak kabul edilebilir kesinti süreniz bir saat ise yedekleme tamamlanmış olabilir, fakat plan tamamlanmış değildir.

Bu hedefleri her önemli hizmet için yazılı olarak belirleyin. Web siteleri, veritabanları, e-posta ve uygulama dosyalarının değişim hızları genellikle farklıdır. Bu, her kurtarma sorununun çözümü olarak tek bir gece alınan sunucu imajını kullanma şeklindeki yaygın hatayı önler.

Sunucu Yedekleme Kontrol Listesi: Neler Korunmalı​

Yararlı bir yedekleme, görünür web sitesi dosyalarından daha fazlasını kapsar. Geri yükleme hataları genellikle gözden kaçan bir bağımlılığın geride bırakılması nedeniyle oluşur: veritabanı parolası, SSL sertifikası, e-posta hesabı veya özel hizmet yapılandırması.

Herhangi bir şeyi otomatikleştirmeden önce yedekleme kümesini tanımlamak için bu kontrol listesini kullanın:

  • Web sitesi dosyaları ve yüklemeler: Belge kök dizinlerini, uygulama kodunu, medya kitaplıklarını ve normal web dizininin dışında depolanan dosyaları dahil edin.
  • Veritabanları: Her veritabanını yedekleyin ve gerektiğinde tabloların, yordamların, tetikleyicilerin ve kullanıcı izinlerinin dahil edildiğini doğrulayın.
  • E-posta verileri: E-posta sunucuda barındırılıyorsa posta kutularını, diğer adları, yönlendirme kurallarını, spam ayarlarını ve hesap kimlik bilgilerini koruyun.
  • Sunucu ve hizmet yapılandırması: Web sunucusu sanal ana bilgisayarlarını, PHP ayarlarını, güvenlik duvarı kurallarını, zamanlanmış görevleri, DNS bölgelerini ve ilgili uygulama yapılandırma dosyalarını kaydedin.
  • SSL sertifikaları ve anahtarları: Yeni bir sertifika düzenlenebilir, ancak özgün anahtar malzemesine ve yenileme yapılandırmasına sahip olmak stresli bir kurtarma sırasında zaman kazandırır.
  • Kullanıcı hesapları ve erişim bilgileri: Yönetici erişimini, SSH anahtarlarını, kontrol paneli kullanıcılarını ve kimlik bilgileri için kurtarma prosedürünü belgeleyin.
  • Günlükler ve iş kayıtları: Sorun giderme veya uyumluluk için gereken günlükleri saklayın, ancak amaçsızca yedekleme alanı tüketmemeleri için gerçekçi saklama süreleri belirleyin.

Yönetilen bir barındırma ortamında, hesap düzeyindeki yedeklemeler rutin web sitesi geri yüklemeleri için yeterli olabilir. Özel hizmetlere, birden fazla uygulamaya veya alışılmadık bir yapılandırmaya sahip bir sunucu için sistem düzeyinde yedeklemeler de ekleyin. Bu, neyi yeniden oluşturmanız gerektiğine ve çalışır hale getirmeniz için ne kadar süreye ihtiyaç duyduğunuza bağlıdır.

Birden Fazla Kopya Kullanın​

Yedeklemeleri aynı sunucuda tutmak, yalnızca yedekleme bu silme işleminden yalıtılmışsa yanlışlıkla silinmeye karşı koruma sağlar. Disk arızasına, fidye yazılımına, güvenliği ihlal edilmiş bir yönetici hesabına veya veri merkezindeki arızaya karşı koruma sağlamaz.

Pratik bir kural 3-2-1 yaklaşımıdır: verilerin en az üç kopyasını iki farklı depolama türünde tutun ve kopyalardan birini tesis dışında depolayın. Birçok ekip için bu; sunucudaki üretim verileri, ayrı depolamadaki bir yedekleme ve farklı bir konumdaki başka bir şifrelenmiş kopya anlamına gelir.

Tesis dışındaki kopya, ana sunucuda ciddi bir sorun olduğunda en çok önem taşır. Yedekleme depolaması, mümkün olduğunda üretim sunucusundakilerden ayrı kimlik bilgileri kullanmalıdır. Tek bir çalınmış parola hem web sitesini hem de tüm yedeklemeleri silebiliyorsa kurtarma planında çok belirgin bir zayıf nokta vardır.

Kritik yedeklemeler için değişmezliği veya silme korumasını değerlendirin. Bu özellikler, yedeklemelerin değiştirilme veya kaldırılma hızını sınırlar; bu da bir fidye yazılımı olayı sırasında değerli olabilir. Ayrıca bir ödünleşim sunarlar: Hataları düzeltmek zorlaşabilir; bu nedenle saklama ve silme ayarlarını kimin değiştirebileceğini belirleyin.

Zamanlamaları Değişim Hızlarına Uygun Ayarlayın​

Statik bir web sitesi günlük yedeklemelerle idare edebilir. Sık düzenlemeler, müşteri gönderimleri veya e-ticaret etkinliği olan bir WordPress sitesi, veritabanı ve yüklenen içerik için daha sık koruma gerektirir.

Yaygın bir yaklaşım, günlük tam yedeklemeler gerçekleştirmek, birkaç haftalık kurtarma noktasını saklamak ve aylık kopyaları daha uzun süre tutmaktır. Veritabanları, dosyalardan daha sık yedekleme gerektirebilir. Uygulamanız işlem günlüklerini veya belirli bir zamana geri kurtarmayı destekliyorsa, güncel verilerin değeri ek kurulum ve depolama maliyetini haklı çıkardığında bunları kullanın.

Sık yedeklemeleri sınırsız saklama süresiyle karıştırmayın. Her sürümü sonsuza kadar saklamak pahalı hale gelir ve ihtiyacınız olan sürümü bulmayı zorlaştırır. Operasyonel ihtiyaçlara, müşteri taahhütlerine ve yasal gerekliliklere dayalı bir saklama politikası tanımlayın. Ardından işletme değiştikçe politikayı gözden geçirin.

Yedeklemeleri Şifreleyin ve Erişimi Sınırlandırın​

Yedeklemeler genellikle bir saldırganın isteyebileceği her şeyi içerir: müşteri verileri, yapılandırma dosyalarında saklanan parolalar, özel anahtarlar ve uygulama sırları. Yedekleme verilerini aktarım sırasında ve beklemede şifreleyin. Şifreleme anahtarlarını koruyun ve acil durumda bunlara kimlerin erişebileceğini belgeleyin.

Erişim, sunucu yönetimiyle aynı ilkeyi izlemelidir: yalnızca ihtiyaç duyan kişi ve sistemler erişime sahip olmalıdır. Ayrı yedekleme kimlik bilgileri, kullanılabildiği yerlerde çok faktörlü kimlik doğrulama ve yönetimsel değişiklikler için etkinlik günlüğü kullanın.

Gözden kaçan bir operasyonel ayrıntı daha vardır: kurtarma erişiminin geri yüklemeye çalıştığınız sunucuya bağlı olmadığından emin olun. Acil durum iletişim bilgilerini, hesap kurtarma bilgilerini, şifreleme anahtarı prosedürlerini ve kısa bir geri yükleme çalışma kılavuzunu sunucunun dışında güvenli bir konumda saklayın.

İhtiyaç Duymadan Önce Geri Yüklemeyi Test Edin​

Yedekleme işleri, eksik arşivler, bozuk veritabanı dökümleri veya artık mevcut uygulama kurulumu ile eşleşmeyen yedeklemeler oluştururken başarılı olduğunu bildirebilir. Geri yükleme testi, güvenin kanıta dönüştüğü noktadır.

En az üç ayda bir, temsili bir web sitesini ve veritabanını yalıtılmış bir test ortamına geri yükleyin. Sitenin yüklendiğini, kullanıcıların oturum açabildiğini, güncel verilerin mevcut olduğunu, zamanlanmış görevlerin çalıştığını ve e-posta ya da diğer bağlı hizmetlerin beklendiği gibi davrandığını kontrol edin. İşlemin ne kadar sürdüğünü kaydedin ve RTO'nuzla karşılaştırın.

Sunucuları taşıma, veritabanı altyapısını yükseltme, yedekleme yazılımını değiştirme veya yeni bir uygulama ekleme gibi önemli değişikliklerden sonra daha sık test yapın. Bir değişiklikten sonra yapılan beş dakikalık test, kesinti sırasında eksik bir bağımlılık keşfetmekten çok daha kolaydır.

FASTPANEL, web sitelerini, veritabanlarını ve hesapları tek bir yerde tutarak rutin sunucu yönetimini daha görünür hale getirebilir; ancak sorumluluk aynıdır: yedekleme kapsamınızın ve geri yükleme sürecinizin gerçek ortamınızla eşleştiğini doğrulayın.

Yedekleme Sürecini İzleyin​

Uyarıları olmayan bir yedekleme zamanlaması, operasyonel bir sistem değil, takvim hatırlatıcısıdır. Başarısız işler, kaçırılan zamanlamalar, düşük depolama kapasitesi, kimlik doğrulama hataları ve olağandışı derecede küçük yedekleme boyutları için bildirimleri yapılandırın. Aniden küçülen bir yedekleme, bir veritabanının, dizinin veya hesabın atlandığını gösterebilir.

Yedekleme raporlarını düzenli bir zamanlamayla inceleyin. Yavaş işleri, artan depolama kullanımını, tekrarlanan uyarıları ve korunan veri miktarındaki değişiklikleri arayın. Sunucuyu birden fazla kişi yönetiyorsa sorumluluğu açıkça atayın. Bir kişi son başarılı yedeklemenin ne zaman çalıştırıldığını, nerede depolandığını ve geri yüklemenin nasıl başlatılacağını bilmelidir.

Adımları açık ve sade bir dille belgeleyin. Bir olay sırasında hiç kimse bulmaca gibi yazılmış bir kurtarma prosedüründen fayda görmez. İşlem sırasını, beklenen geri yükleme sürelerini, DNS ile ilgili hususları, doğrulama kontrollerini ve ne zaman yardım isteneceğine ilişkin karar noktasını dahil edin.

Sakin bir kurtarma, kesinti yaşanmadan önce oluşturulur. Kapsamı belirleyin, kopyaları birbirinden ayırın, erişimi koruyun ve geri yükleme işlemini uygulayın. Böylece yedeklemeler arka planda çalışan bir görev olmaktan çıkar ve olması gereken şeye dönüşür: geri dönüş için güvenilir bir yol.