Bir web sitesinin başına gelebilecek en sinir bozucu şeylerden biri, "bir şeyler ters gitti" anıyla "en son ne zaman düzgün çalışıyordu?" sorusu arasında sıkışıp kalmaktır. Yanlış silinen bir klasör, bozuk bir eklenti güncellemesi, kötü bir veritabanı sorgusu ya da bir güvenlik ihlali dakikalar içinde canlı sitenizi kullanılamaz hale getirebilir. İşte tam bu noktada JetBackup devreye girer: hosting hesabınızın düzenli aralıklarla alınmış "zaman noktalarını" (restore point) saklar ve gerektiğinde bu noktalardan yalnızca ihtiyacınız olanı — tek bir dosyayı, tek bir veritabanını ya da hesabın tamamını — geri getirmenizi sağlar.
Bu rehberde JetBackup'ın cPanel arayüzü üzerinden bir yedek noktasını nasıl seçeceğinizi, dosya ve veritabanını nasıl seçici (selective) biçimde geri yükleyeceğinizi, tam hesap restore ile parçalı restore arasındaki farkı ve en önemlisi geri yükleme öncesi mevcut durumu koruyarak "daha kötü hale getirmeden" nasıl kurtarma yapacağınızı adım adım ele alacağız. Silinen dosya, hacklenen site ve bozuk güncelleme gibi gerçek senaryolar üzerinden ilerleyeceğiz; böylece panik anında ne yapmanız gerektiğini önceden bilerek hareket edeceksiniz.
JetBackup Nedir ve Klasik cPanel Yedeğinden Farkı#
JetBackup, cPanel/WHM sunucularına entegre çalışan üçüncü taraf bir yedekleme ve geri yükleme çözümüdür. Klasik cPanel Backup aracı size tek bir anlık .tar.gz dosyası verirken, JetBackup sürüm bazlı çalışır: her yedekleme çalıştırıldığında ayrı bir "restore point" oluşturulur ve saklama süresi (retention) boyunca birden fazla geçmiş sürüm elinizde tutulur. Yani sadece dünkü hali değil, geçen haftaki ya da bir ay önceki halini de geri getirebilirsiniz.
En kritik fark seçici geri yüklemedir. Klasik yöntemde bozuk bir tabloyu düzeltmek için genellikle koca bir arşivi indirir, açar, tek dosyayı bulur ve elle yüklersiniz. JetBackup'ta ise yedek noktasının içine girip yalnızca o tek klasörü, o tek veritabanını ya da o tek e-posta hesabını işaretleyip geri yükleyebilirsiniz. Aşağıdaki tablo iki yaklaşımı özetliyor:
| Özellik | Klasik cPanel Backup | JetBackup |
|---|---|---|
| Sürüm sayısı | Tek anlık dosya | Çok sayıda restore point |
| Seçici dosya restore | Manuel (indir-aç-yükle) | Arayüzden tek tık |
| Seçici veritabanı restore | Manuel içe aktarım | Panelden doğrudan |
| Otomatik zamanlama | Sınırlı | Günlük/haftalık planlı |
| Geri yükleme yeri | Genellikle üzerine yazar | Aynı yer veya farklı hedef |
JetBackup'ın klasik araçlara temel bir alternatif değil, onun üzerine kurulu daha yetenekli bir katman olduğunu unutmayın. cPanel'in kendi yedekleme mantığını da bilmek isterseniz cPanel yedekleme rehberimize göz atabilirsiniz.
Bir Restore Point (Yedek Noktası) Seçmek#
Her geri yükleme işlemi doğru zaman noktasını seçmekle başlar. cPanel'e giriş yaptıktan sonra arama kutusuna "JetBackup" yazın ve genellikle "Files", "Databases", "Email" ve "Full Account" başlıklarına ayrılmış menüyü göreceksiniz. Hangi başlığa girerseniz girin, ilk yapmanız gereken hangi tarihteki yedeğe döneceğinize karar vermektir.
Restore point seçerken en yaygın hata, "en yeni yedeği" refleksle seçmektir. Oysa sorun ne zaman ortaya çıktıysa, ondan önceki son sağlıklı noktayı seçmelisiniz. Örneğin bugün öğlen bir eklenti güncellemesi siteyi bozduysa, bu sabahki değil, dünkü ya da güncelleme öncesindeki yedeğe dönmelisiniz — aksi halde bozuk halin yedeğini geri yüklersiniz. Zaman çizelgesini şu mantıkla değerlendirin:
- Sorunun kesin olarak ne zaman başladığını belirleyin (site günlükleri, e-posta uyarıları, müşteri şikâyeti).
- O andan önceki en yakın restore point'i hedefleyin.
- Emin değilseniz, bir gün daha geriye gitmek genellikle daha güvenlidir.
Sunucu saat dilimi ile sizin saatiniz farklı olabileceği için yedek noktalarının tarih-saatini dikkatle okuyun. Karışıklığı önlemek adına, geri yükleme öncesi hangi noktayı seçtiğinizi bir yere not almak iyi bir alışkanlıktır.
Dosyaları Seçici Olarak Geri Yükleme#
Diyelim ki bir tema düzenlemesi sırasında wp-content/themes altındaki bir dosyayı yanlışlıkla sildiniz ya da FTP ile yaptığınız bir yükleme yarıda kesildi. Tüm hesabı geri yüklemeye gerek yok; yalnızca ilgili klasörü kurtarmak yeterli. JetBackup'ta "File Backups" bölümüne girip uygun restore point'i açtığınızda, hesabınızın dosya ağacını tıpkı bir dosya yöneticisi gibi gezebilirsiniz.
Buradan geri getirmek istediğiniz klasörü ya da tek tek dosyaları işaretler, "Restore Selected" (Seçilenleri Geri Yükle) düğmesine basarsınız. JetBackup seçtiğiniz öğeleri mevcut konumlarının üzerine yazarak eski haline döndürür. Örneğin yalnızca yükleme klasörünü kurtarmak istiyorsanız, tüm siteyi değil sadece o yolu seçmeniz yeterli olur:
# Geri yüklenecek örnek dizin yolu
/home/kullanici/public_html/wp-content/uploads/2026/07
Bu yaklaşımın en büyük avantajı izolasyondur: siteniz büyük oranda sağlamken sadece bir bölümü bozulduysa, geri kalan tüm değişikliklerinizi (yeni yazılar, yeni siparişler, yeni yorumlar) kaybetmeden yalnızca hasarlı parçayı onarabilirsiniz. Geri yükleme kuyruğa alınır; büyük klasörlerde işlem birkaç dakika sürebilir ve tamamlandığında cPanel size bildirim gönderir. WordPress özelinde dosya ve veritabanı yedeğini birlikte düşünmek gerekir — bu ikisinin nasıl uyumlu yönetileceğini WordPress yedekleme yazımızda ayrıntılı anlattık.
Veritabanını Geri Yükleme#
Web sitelerindeki hasarın büyük kısmı aslında dosyalarda değil, veritabanında yaşanır. Yanlış çalıştırılan bir DELETE sorgusu, bozuk bir eklenti kurulumu ya da yarım kalan bir güncelleme tabloları darmadağın edebilir. JetBackup'ın "Database Backups" bölümü tam da bunun içindir: restore point'i seçtikten sonra hesabınıza ait veritabanlarının listesini görür ve yalnızca geri yüklemek istediğini işaretlersiniz.
Burada dikkat edilmesi gereken önemli bir nokta var: veritabanı geri yükleme neredeyse her zaman üzerine yazma (overwrite) mantığıyla çalışır. Yani seçtiğiniz veritabanı, yedekteki haliyle tamamen değiştirilir ve o yedekten sonra eklenen tüm kayıtlar (yeni siparişler, üyeler, yorumlar) silinir. Bu yüzden geri yüklemeden önce mutlaka mevcut veritabanının bir dökümünü almalısınız. SSH erişiminiz varsa hızlı bir yedek şöyle alınır:
# Geri yükleme öncesi mevcut veritabanının güvenlik dökümü
mysqldump -u kullanici -p veritabani_adi > /home/kullanici/gecici_yedek.sql
Geri yükleme tamamlandıktan sonra sitenizin bağlantı ayarlarının hâlâ doğru veritabanını gösterdiğini kontrol edin. WordPress kullanıyorsanız wp-config.php içindeki değerlerin yedekle uyumlu olduğundan emin olun:
define( 'DB_NAME', 'veritabani_adi' );
define( 'DB_USER', 'kullanici' );
define( 'DB_HOST', 'localhost' );
Eğer geri yükleme sonrası "veritabanı bağlantı hatası" alırsanız, sorun genellikle veritabanı kullanıcısının yetkilerinin ya da tablo ön ekinin (wp_ gibi) uyuşmamasından kaynaklanır. Böyle bir durumda yedeği aynı isimli boş bir veritabanına geri yükleyip ayarları buna göre güncellemek daha temiz bir çözüm olur.
Tam Hesap (Full Account) Restore ve Ne Zaman Kullanılmalı#
Bazı durumlarda hasar o kadar yaygındır ki tek tek parçaları kurtarmaya çalışmak zaman kaybıdır. Sunucu taşındı, hesap bütünüyle silindi ya da site baştan aşağı ele geçirildiyse, JetBackup'ın "Full Account Backups" bölümünden tüm hesabı tek seferde geri yüklemek en mantıklı yoldur. Bu işlem dosyaları, tüm veritabanlarını, e-posta hesaplarını, DNS kayıtlarını, cron işlerini ve hesap ayarlarını birlikte eski haline döndürür.
Full restore güçlüdür ama aynı ölçüde geniş etkilidir; seçtiğiniz yedek noktasından sonraki her şey kaybolur. Bu yüzden karar verirken parçalı ve tam restore'u şu ölçütlerle karşılaştırın:
| Senaryo | Önerilen yöntem |
|---|---|
| Tek dosya/klasör silindi | Seçici dosya restore |
| Sadece veritabanı bozuldu | Seçici veritabanı restore |
| Bir eklenti güncellemesi patladı | Dosya + veritabanı restore |
| Site tamamen hacklendi | Tam hesap restore |
| Hesap yanlışlıkla silindi | Tam hesap restore |
| Yeni sunucuya taşıma | Tam hesap restore |
Genel kural şudur: hasarın kapsamı ne kadar dar ise, o kadar seçici bir restore tercih edin. Böylece geri yükleme noktasından bu yana yapılmış meşru değişiklikleri gereksiz yere feda etmezsiniz. Çok kapsamlı taşıma ve kurtarma operasyonlarında profesyonel destek almak isterseniz site taşıma ve sunucu yönetimi hizmetlerimiz bu tür işlerde devreye girer.
Kritik Senaryolar: Hacklenen Site, Silinen Dosya, Bozuk Güncelleme#
Teoriyi gerçek durumlara oturtalım. Aşağıdaki üç senaryo, JetBackup restore işlemlerinin pratikte en sık kullanıldığı durumlardır ve her birinin kendine özgü incelikleri vardır.
Hacklenen site. Bir güvenlik ihlalinde en tehlikeli hata, saldırı tespit edildikten sonra alınmış bir yedeğe dönmektir — çünkü o yedek büyük olasılıkla arka kapıyı (backdoor) da içerir. Doğru yaklaşım, ihlalin başladığı tarihten öncesine ait bir restore point seçmektir. İhlalin ne zaman başladığını bilmiyorsanız sunucunun giriş ve hata kayıtlarını inceleyerek ilk şüpheli aktivitenin tarihini belirleyin ve restore point'i buna göre seçin. Geri yükleme sonrası tüm parolaları değiştirmeyi, eklenti ve çekirdek sürümlerini güncellemeyi ve mümkünse bir WAF katmanı eklemeyi ihmal etmeyin.
Yanlışlıkla silinen dosya. Bu en tatlı senaryodur çünkü çözümü basittir. Silinen dosyanın tam yolunu biliyorsanız, uygun restore point'ten sadece o dosyayı ya da klasörü seçip geri yüklersiniz. Silme işlemi çok yeni ise, en son alınan yedeğin bile bu dosyayı içerdiğinden emin olmak için yedek noktasının zaman damgasını kontrol edin.
Bozuk güncelleme. Bir eklenti veya tema güncellemesi siteyi çökertirse, çoğu zaman hem dosyalar hem de veritabanı etkilenmiştir. Böyle durumlarda güncelleme öncesindeki restore point'ten hem dosya hem veritabanını birlikte geri yüklemek gerekir. Sadece birini geri yüklerseniz, veritabanı şeması ile kod uyumsuz kalabilir ve site yine açılmaz. İkisini aynı yedek noktasından eş zamanlı geri getirmek tutarlılığı korur.
Geri Yükleme Öncesi Mevcut Durumu Yedekleyin#
Geri yükleme dünyasında en çok pişmanlık yaratan cümle şudur: "Yedeğe döndüm ama meğer son bir haftanın verisi de gitmiş." Restore işlemleri geri alınamaz değildir, ancak bir yedek noktasına dönmek, o noktadan bu yana biriken tüm meşru değişiklikleri de siler. Bu yüzden altın kural, herhangi bir restore'a başlamadan önce mevcut halin taze bir yedeğini almaktır.
Bunu yapmanın en pratik yolu, restore'dan hemen önce yeni bir yedek çalıştırmak ya da elle bir döküm almaktır. Böylece "yanlış noktaya döndüm" ya da "aslında son verilere ihtiyacım varmış" dediğinizde geri dönebileceğiniz bir güvenlik ağınız olur. SSH erişiminiz varsa hem dosya hem veritabanı için hızlıca şöyle bir emniyet kopyası oluşturabilirsiniz:
# Dosyaların anlık arşivi
tar -czf /home/kullanici/restore_oncesi_$(date +%F).tar.gz /home/kullanici/public_html
# Veritabanının anlık dökümü
mysqldump -u kullanici -p veritabani_adi > /home/kullanici/restore_oncesi_$(date +%F).sql
Bu iki adımı alışkanlık haline getirdiğinizde, en kötü ihtimalle bile başladığınız yere geri dönebilirsiniz. Yedekleme stratejinizi tümüyle ele almak, saklama sürelerini ve dış konum kopyalarını planlamak isterseniz yedekleme hizmetimiz süreci sizin için otomatikleştirir; böylece kurtarmaya ihtiyaç duyduğunuz anda elinizde her zaman güvenilir bir nokta bulunur.
Restore Sonrası Kontrol Listesi#
Geri yükleme "tamamlandı" bildirimini görmeniz işin bittiği anlamına gelmez; asıl doğrulama sitenin gerçekten sağlıklı çalıştığını görmektir. Aceleyle "oldu" deyip geçmek, günler sonra fark edilen sessiz hataların başlıca sebebidir. Restore biter bitmez şu kontrolleri sırayla yapın:
- Ana sayfa ve birkaç iç sayfa açılıyor mu, görseller yükleniyor mu?
- Yönetici paneline (WordPress, özel panel vb.) giriş yapabiliyor musunuz?
- Formlar, ödeme akışı ve arama gibi dinamik işlevler çalışıyor mu?
- E-posta gönderimi ve alımı düzgün mü?
- SSL sertifikası hâlâ geçerli mi, tarayıcı uyarı veriyor mu?
Bir eksiklik görürseniz, çoğu zaman sorun önbellekten kaynaklanır. Tarayıcı önbelleğini, varsa CDN önbelleğini ve sunucu tarafı önbelleği temizleyin. DNS ya da SSL tarafında bir tutarsızlık sürüyorsa, sertifikayı yenilemek için SSL yapılandırmanızı gözden geçirin. Kritik bir siteyseniz, restore sonrası ilk 24 saat boyunca hata kayıtlarını daha sık kontrol etmek, gözden kaçan bir aksaklığı erken yakalamanızı sağlar.
Sıkça Sorulan Sorular#
JetBackup ile geri yükleme yaptığımda mevcut verilerim silinir mi?#
Seçici geri yüklemede yalnızca işaretlediğiniz dosya ya da veritabanı, yedekteki haliyle değiştirilir; dokunmadığınız her şey olduğu gibi kalır. Ancak veritabanı ve tam hesap restore işlemleri üzerine yazma mantığıyla çalıştığından, seçtiğiniz yedek noktasından sonra eklenen kayıtlar kaybolur. Bu nedenle geri yüklemeden önce mutlaka mevcut durumun ayrı bir yedeğini almanız gerekir.
Hangi yedek noktasını seçmeliyim, en yenisini mi?#
En yeni yedek her zaman doğru seçim değildir. Sorun ne zaman ortaya çıktıysa, ondan hemen önceki son sağlıklı restore point'i seçmelisiniz. Örneğin bozuk bir güncelleme ya da bir güvenlik ihlali söz konusuysa, o olaydan sonraki bir yedeğe dönmek bozuk ya da ele geçirilmiş hali geri yüklemenize yol açar; bu yüzden olayın öncesindeki bir noktayı hedefleyin.
Sadece tek bir dosyayı geri yükleyebilir miyim?#
Evet, JetBackup'ın en güçlü yanlarından biri budur. File Backups bölümünde ilgili restore point'i açıp dosya ağacında gezinerek yalnızca tek bir dosyayı ya da klasörü işaretleyip geri yükleyebilirsiniz. Bu sayede tüm siteyi etkilemeden, geri kalan verilerinizi kaybetmeden yalnızca hasarlı parçayı kurtarmış olursunuz.
Hacklenen sitemi geri yükledim ama tekrar hacklendi, neden?#
Bunun en yaygın sebebi, saldırıdan sonra alınmış bir yedeğe dönmüş olmanızdır; o yedek büyük olasılıkla saldırganın bıraktığı arka kapıyı da içeriyordu. İhlalin başladığı tarihten öncesine ait temiz bir restore point seçmeli, geri yükleme sonrasında tüm parolaları değiştirmeli, yazılım sürümlerinizi güncellemeli ve mümkünse bir güvenlik duvarı katmanı eklemelisiniz.
Geri yükleme ne kadar sürer?#
Süre tamamen yedeğin boyutuna ve seçtiğiniz kapsama bağlıdır. Tek bir küçük dosya birkaç saniyede dönerken, gigabaytlarca veri içeren tam hesap restore işlemi onlarca dakika sürebilir. JetBackup işlemleri arka planda kuyruğa alır ve tamamlandığında hesabınıza tanımlı e-postaya bildirim gönderir, dolayısıyla süreç boyunca tarayıcıyı açık tutmanız gerekmez.
Geri yükleme yanlış gitti, geri alabilir miyim?#
Restore işleminin kendisinin bir "geri al" düğmesi yoktur, bu yüzden emniyet ağı işleme başlamadan önce oluşturulmalıdır. Eğer geri yüklemeden hemen önce mevcut durumun bir yedeğini aldıysanız, o yedeği geri yükleyerek başladığınız noktaya dönebilirsiniz. Bu yedeği almadıysanız kayıp kalıcı olabilir; işte bu yüzden her restore öncesi taze bir güvenlik kopyası almak vazgeçilmez bir alışkanlıktır.
Kapanış#
JetBackup, veri kaybını bir felaketten sıradan bir "birkaç dakikalık işleme" dönüştüren güçlü bir araçtır; ancak asıl fark, aracı değil disiplini olan kullanıcılarda ortaya çıkar. Doğru restore point'i seçmek, hasarın kapsamına uygun (seçici ya da tam) yöntemi belirlemek ve her şeyden önce geri yükleme öncesinde mevcut durumu yedeklemek — bu üç alışkanlık, çoğu kurtarma senaryosunu sorunsuz atlatmanızı sağlar.
Sitenizi düzenli, sürüm bazlı ve JetBackup gibi profesyonel araçlarla korunan bir altyapıda barındırmak istiyorsanız, Clou.TR'nin web hosting ve WordPress hosting paketleri günlük otomatik yedeklerle gelir. Daha fazla kaynak ve tam yönetim gerektiren projeler için sanal sunucu çözümlerimizi inceleyebilir, kurtarma ve bakım süreçlerini uzmanlarımıza bırakmak isterseniz sunucu yönetimi ve yedekleme hizmetlerimizle sitenizin güvenliğini bize emanet edebilirsiniz.