VPS ve VDS yedekleme planı: snapshot, yedek ve geri yükleme
Bu rehberin sonunda: Neyi yedekleyeceğinizi, kopyayı nerede tutacağınızı ve geri yüklemeyi nasıl deneyeceğinizi yazılı hale getireceksiniz. Yedek, sorun olduğunda geri dönebileceğiniz veri kopyasıdır.
Sunucu yedekleme planı, hangi veriyi ne sıklıkta kopyalayacağınızı ve gerektiğinde nasıl geri döneceğinizi tanımlar. Bir yedekleme işinin tamamlanması, uygulamanın o kopyadan çalışır durumda açılabildiğini tek başına göstermez.
Kapsam: Kendi yönettiğiniz VPS, VDS veya fiziksel sunucu için planlama. Belirli bir yedekleme yazılımının kurulumunu ya da müşteri panelinde sunulduğu doğrulanmamış işlemleri anlatmaz. Web hosting yedekleme koşulları için hosting yedekleme rehberini kullanın.
Aynı arızadan etkilenebilen kopyalar bağımsız koruma sağlamaz.
- Aynı diskte kopya
Yanlış düzenlemeden dönüşe yarayabilir. Disk arızasında asıl veriyle birlikte kaybolabilir.
- Sanal makine snapshot'ı
Desteklendiği yerde durum noktasına dönüş sağlar. Aynı depolamadan bağımsız koruma sayılmaz.
- Ayrı hedefte yedek
Kaynak sunucudan ayrı kopyadır. Erişim, saklama ve geri yükleme testi ayrıca gerekir.
Snapshot kapsamı ve yedekleme hizmeti pakete bağlıdır; dahil olduğunu varsaymayın.
1. Hizmette neyin dahil olduğunu netleştirin
DCHost müşteri portalındaki hizmet bilgilerinden veya destek ekibinden doğrulayın:
- Pakette yedekleme var mı?
- Varsa hangi verileri ve diskleri içeriyor?
- Kopyalar ne kadar saklanıyor?
- Geri yüklemeyi kim, hangi yöntemle yapıyor?
Kontrol: “Yedek var” cevabıyla yetinmeyin; geri dönebileceğiniz tarih ve geri yükleme yolu belli olmalı.
DCHost sanal sunucu altyapısında Proxmox/KVM kullanılır. Bu bilgi, her pakette otomatik yedekleme, müşteri erişimine açık snapshot veya belirli bir saklama süresi bulunduğu anlamına gelmez. Ürününüzde dahil bir yedekleme hizmeti yoksa işletim sistemi, uygulama ve veri yedeklerini ayrıca planlamanız gerekir.
Destek ekibiyle kapsam belirleyecekseniz sunucu numarası, veri türü, veri boyutu, değişim sıklığı, saklama süresi ve geri yükleme ihtiyacını paylaşın. Yedek alınacak sunucuya erişim yetkiniz ve uygulamayı yöneten kişinin katılımı bulunmalıdır.
2. Snapshot ile bağımsız yedeği ayırın
Basit örnek: Aynı diskte farklı klasörlerde duran iki kopya, disk bozulursa birlikte kaybolabilir. Kopyanın varlığı kadar kaynak sunucudan bağımsız saklanması da önemlidir.
| Yöntem | Ne sağlar? | Tek başına neyi çözmez? |
|---|---|---|
| Sunucunun kendi diskindeki kopya | Bazı yanlış düzenlemelerden hızlı dönüş | Aynı disk/sunucu arızası, hesabın ele geçirilmesi |
| Sanal makine snapshot'ı | Desteklenen altyapıda belirli duruma dönüş | Aynı depolama arızasından bağımsız koruma ve uzun süreli saklama |
| Ayrı hedefte saklanan yedek | Kaynak sunucudan ayrı geri yükleme kopyası | Erişim ve saklama yanlış ayarlanmışsa silinmeye karşı kesin koruma |
| Uygulamaya uygun veri yedeği | Dosya ve veritabanının tutarlı geri dönüşü | İşletim sistemi, diğer servisler ve bağımlılıkların tamamı |
Snapshot'ın kapsamı depolama ve sanal makine ayarlarına bağlıdır. Bellek durumunu, bağlı tüm diskleri veya dış veritabanını içerdiğini varsaymayın. Proxmox'ta “snapshot mode” adlı yedekleme yöntemi ile bir sanal makine snapshot'ı da aynı işlem değildir. Canlı veritabanlarında uygulama tutarlılığı ayrıca sağlanmalıdır; yalnız dosyaları kopyalamak yeterli olmayabilir.
3. Geri dönüş hedefini işinize göre seçin
İki boşluğu doldurun:
- Veri hedefim: En fazla ___ dakikalık/saatlik yeni veriyi kaybetmeyi kabul edebilirim.
- Süre hedefim: Hizmetin yeniden çalışması için en fazla ___ dakika/saat ayırabilirim.
Bunlar sizin planlama hedeflerinizdir; paketiniz için verilmiş garanti değildir.
İki sorunun yanıtını yazın: En fazla ne kadar yeni veriyi kaybetmeyi kabul edebilirsiniz? Bu, RPO hedefinizdir. Hizmetin yeniden çalışması için ne kadar süre ayırabilirsiniz? Bu da RTO hedefidir.
Örneğin her gün sipariş alan bir mağazada yalnız haftalık kopya, gün içindeki sipariş kaybı beklentinize uymayabilir. Hedefler hizmet garantisi değildir; yedekleme sıklığı, aktarım süresi ve gerçek geri yükleme denemesiyle karşılanıp karşılanamadıklarını ölçmeniz gerekir.
4. Yedeğe girecek verileri listeleyin
Bir liste hazırlayıp her satırın hangi yedeğe dahil olduğunu yazın:
- Uygulama dosyaları ve yüklenen belgeler.
- Veritabanı.
- Gerekli ayarlar ve zamanlanmış işler.
- Varsa e-posta ve dış depolama.
- Yeniden kurulumda gerekecek bağımlılık bilgileri.
Kontrol: Dosya yedeğinin veritabanını da içerdiğini varsaymayın; her veri türünü doğrulayın.
Uygulama dosyaları, yüklenen belgeler, veritabanları, yapılandırma, zamanlanmış görevler ve gerekiyorsa e-posta verilerini birlikte değerlendirin. Harici nesne depolama veya başka sunucudaki veritabanını unutmayın. Parola ve anahtar içeren ayar dosyaları gerekiyorsa yedeği şifreleyin; açma anahtarını yalnız kaynak sunucuda tutmayın.
Veritabanı için kendi yazılımının desteklediği yedekleme yöntemi kullanılmalıdır. Canlı veritabanı dizinini rastgele arşivlemek, tamamlanmış gibi görünen ama geri açılamayan bir kopya oluşturabilir. Dosya ve veritabanının aynı zamana ait olmasını planlayın.
Tutarlılık örneği: Bir yükleme kaydı veritabanında var ama karşılık gelen dosya yedekte yoksa uygulama eksik açılabilir. Dosyalarla veritabanının uyumlu bir noktaya döndüğünü test edin.
5. Saklama ve izlemeyi belirleyin
Planınıza dört bilgiyi ekleyin: yedek hedefi → alma sıklığı → saklanacak sürümler → hata bildirimini alacak kişi.
Yedeği kaynak sunucudan ayrı bir hedefte saklayın. Erişim yetkilerini sınırlandırın; kaynak hesaba erişen kişinin bütün geçmiş kopyaları da silebildiği bir düzenin riskini değerlendirin. Kaç günlük/haftalık sürüm tutacağınızı ve kapasite sınırını belirleyin.
Yedekleme hatası, beklenmedik boyut değişikliği ve hedefte alan azalması için bildirim planlayın. Yedekleri herkese açık web dizinine koymayın. Şifreleme, erişim kontrolü ve geri yükleme anahtarını birlikte yönetin.
6. Ayrı ortamda geri yükleyerek doğrulayın
Başarılı yedekleme kaydı, geri yükleme denemesinin yerine geçmez.
- Bir tarih seçin
Hangi noktaya döneceğinizi ve beklediğiniz kayıtları belirleyin.
- Test ortamına yükleyin
Canlı veriye dokunmadan, yedeği erişimi kısıtlı test ortamına geri yükleyin. Uygulamayı açmadan gerçek bildirim ve ödeme işlemlerini engelleyin.
- Veriyi kontrol edin
Giriş yapabildiğinizi, dosyaların açıldığını ve önemli kayıtların doğru olduğunu kontrol edin.
- Süreyi kaydedin
Yedek tarihini ve geri yükleme süresini not edin; hedefinize uyup uymadığını kontrol edin.
Gerçek geri dönüşte yedekten sonra oluşan sipariş ve kayıtları nasıl koruyacağınızı önceden planlayın.
Gerçek bir geri yükleme denemesi yapın:
- Canlı sunucudan ayrı, erişimi kısıtlı test ortamı hazırlayın.
- Uygulama açılmadan önce e-posta, ödeme ve zamanlanmış görevlerin gerçek müşterilere işlem yapmasını engelleyin.
- Seçtiğiniz tarihli yedeği bu korumalı ortama geri yükleyin.
- Dosya, giriş ve önemli kayıtları kontrol edin.
- Geri yükleme süresini ve yedek tarihini not edin.
Beklenen sonuç: Uygulama test ortamında açılır ve seçilen yedek tarihindeki önemli veriler doğrulanır. Yedek dosyasının mevcut olması bu testin yerini tutmaz.
Canlı sunucunun üzerine yazmadan, erişimi kısıtlı bir test ortamına dönün. Geri yüklenen uygulamanın müşterilere e-posta göndermesini, ödeme işlemi başlatmasını ve zamanlanmış görevleri tekrar çalıştırmasını önleyin. Kritik kayıt, dosya, giriş ve uygulama işlemlerini kontrol edin; işlemin süresini ve yedek tarihini kaydedin.
Geri yükleme öncesinde mevcut verinin kopyasını koruyun. Eski yedeğe dönüş, yedekten sonra oluşan kayıtları kaybettirebilir. Bir güvenlik olayı yaşandıysa yalnız eski kopyayı açmak yeterli değildir; giriş bilgilerini ve açığın nedenini de ele alın. Kullanılabilirliği doğrulanmış başka bir kopya olmadan son yedeği silmeyin.
Geri dönüşten önce: Eski yedekten sonra gelen sipariş ve kayıtları nasıl koruyacağınızı belirleyin. Geri yükleme “yalnız eksikleri eklemek” değildir; yönteme göre mevcut verinin üzerine yazabilir.