Sitem Silindi, Yedeğim Yok: Kurtarma Şansım Var mı?

Yanlış klasörde rm -rf çalıştırdınız, bir taşıma sırasında hedefi kaynakla karıştırdınız, eski hostingi iptal ettiniz ve hesap sonlandırıldı ya da bir geliştirici “temizlik yapıyorum” deyip public_html içini boşalttı. Sonuç aynı: site yok, dosyalar yok ve elinizde yedek yok. Silinen site nasıl kurtarılır diye ararken bulduğunuz her yazı size “yedek almalıydınız” diyor — doğru ama artık işe yaramayan bir öğüt. Bu yazı o cümleyi kurmayacak; yedeğiniz yokken elinizde gerçekten ne kaldığını ve onu nasıl toplayacağınızı anlatacak.

İyi haber şu: “yedeğim yok” çoğu zaman “hiçbir kopya yok” anlamına gelmez. Sağlayıcının sunucu tarafında tuttuğu ve sizin varlığından haberdar olmadığınız bir geri yükleme noktası olabilir; olsa bile ömrü sınırlıdır ve saatler içinde talep edilmezse bir sonraki yedekleme döngüsü onu boş sitenizle üzerine yazar — bu yazıdaki en kritik bilgi budur. Sunucu tarafında hiçbir şey kalmadıysa bile içeriğin önemli bir kısmı arşiv kayıtlarında, arama motoru sonuçlarında, sosyal medya paylaşımlarında ve kendi cihazlarınızda dağınık hâlde duruyordur. Aşağıda bu kaynakları öncelik sırasına göre, her birinin ne kadarını geri getirdiğini ve hangi zaman penceresinde çalıştığını göreceksiniz.

İlk 30 Dakika: Hasarı Durdurun#

Kurtarmanın en büyük düşmanı panik hâlinde yapılan ikinci müdahaledir. Silinmeyi fark ettiğiniz anda yapmamanız gerekenler şunlardır:

1. Aynı hesaba yeni bir kurulum yapmayın. “Nasılsa gitti, WordPress’i baştan kurayım” demek, diskteki eski verinin üzerine yazma ihtimalini artırır ve daha kötüsü, gece çalışacak yedekleme görevinin yeni boş siteyi yedeklemesine yol açar.
2. Hosting hesabınızı iptal etmeyin, silmeyin, paket değiştirmeyin. Sonlandırılmış bir hesabın verisi geri getirilemeyebilir; askıdaki bir hesabınki genelde durur. İki durumun farkı için hosting hesabım askıya alındı yazısına bakabilirsiniz.
3. Alan adına dokunmayın. DNS kayıtlarını değiştirmek, alan adını başka bir yere taşımak kurtarmayı kolaylaştırmaz, sadece karmaşıklaştırır.
4. VDS/sunucu kullanıyorsanız yazma işlemlerini kesin. Silinen dosyalar diskte bir süre daha fiziksel olarak durur; yazmaya devam etmek o alanı gerçekten geri dönülemez hâle getirir.

Yapmanız gerekenler ise ikidir ve ikisi aynı anda başlamalıdır: sağlayıcıya hemen destek talebi açın ve paralel olarak kendi kopya avınızı başlatın. Destek yanıtını beklerken geçen iki saat, arşiv taramasıyla değerlendirilebilecek iki saattir.

Gerçekten Silindi mi, Yoksa Sadece Görünmüyor mu#

Kurtarmaya başlamadan önce beş dakikanızı bunu doğrulamaya ayırın, çünkü “site gitti” diye tanımlanan durumların önemli bir kısmında dosyalar yerinde duruyordur.

• Dosyalar duruyor ama site açılmıyor. Ana dizinde dosyaları görüyorsanız sorun silinme değil yapılandırmadır. Bu, tamamen ayrı bir teşhis sırası gerektirir; site açılmıyor ne yapmalı yazısı o sırayı verir.
• Yanlış dizine bakıyorsunuz. Hesapta birden fazla alan adı varsa asıl site public_html altında, ek alan adları public_html/ornek.com ya da /home/kullanici/ornek.com altında olabilir. Kök dizinde ls -la ile bakın; gizli dosyalar dahil.
• Hesap askıda. Askıdaki bir hesapta dosyalar diskte durur, sadece servis edilmez.
• Alan adı başka yeri gösteriyor. DNS değişikliği sonrası site “boş” görünüyorsa dosyalar eski sunucuda duruyor olabilir.

Doğrulamanın en net yolu dosya sayısına bakmaktır:

ls -la /home/kullaniciadi/public_html | head
find /home/kullaniciadi/public_html -type f | wc -l
du -sh /home/kullaniciadi

Üçüncü komutun sonucu birkaç megabaytsa ve normalde gigabaytlarca veriniz varsa silinme gerçektir. wp-config.php duruyor ama wp-content yoksa kısmi silinme vardır — bu iyi haberdir, çünkü veritabanınız muhtemelen yerindedir ve veritabanı sitenin metin içeriğinin tamamını taşır.

Kurtarma Kaynakları ve Ne Getirdikleri#

Aşağıdaki tablo, elinizdeki tüm olası kaynakları ve gerçekçi beklentiyi gösterir. Sıralama, denemeniz gereken önceliğe göredir.

Tablodaki tek “saatler” yazan satır, en değerli satırdır. Şimdi ona bakalım.

Kaynak 1: Sağlayıcının Sunucu Yedeği — Saat Neden Kritik#

Sunucu tarafı yedekler dönüşümlüdür: yeni yedek alınırken en eski yedek silinir. Bu, silinme olayını yaşadıktan sonra beklemenin neden pahalı olduğunu tek başına açıklar. Gece yarısı çalışan bir yedekleme görevi, ertesi gece sizin boş sitenizi yedekler ve sıra dönüşümünde bir önceki iyi kopyanın yerini alabilir. Yani kaybettiğiniz veri değil, kurtarma penceresidir; ve o pencere saatlerle ölçülür.

Yapılacaklar, bu sırayla:

1. Panelinizde geri yükleme aracı olup olmadığına bakın. Paylaşımlı hostingte bu çoğunlukla cPanel içinde bir yedekleme/geri yükleme bölümüdür. Kendi arayüzünden hangi tarihlerin mevcut olduğunu görebilir ve geri yüklemeyi kendiniz başlatabilirsiniz. JetBackup kullanan bir sunucudaysanız süreç JetBackup geri yükleme yazısında adım adım anlatılıyor.
2. Panelde araç yoksa destek talebini hemen açın. Talebi doğru yazmak, yanıt süresini ciddi biçimde kısaltır. Şu beş bilgiyi tek mesajda verin:
   • Alan adı ve hosting kullanıcı adı.
   • Silinmenin yaklaşık tarih ve saati (log’a bakmadan tahmin edin, yaklaşık yeter).
   • Neyin silindiği: yalnızca dosyalar mı, veritabanı da mı.
   • Talebiniz: “Bu tarihten önceki en yakın yedeğin geri yüklenmesini rica ediyorum.”
   • Kritik cümle: “Sonraki yedekleme döngüsünün mevcut boş hâli yedeklemesini önlemek adına acil işlem rica ediyorum.”
3. Geri yüklemenin nereye yapılacağını netleştirin. Mümkünse mevcut hâlin üzerine değil, ayrı bir dizine geri yüklenmesini isteyin. Böylece silinme sonrasında oluşmuş yeni veri (varsa) kaybolmaz ve iki hâli karşılaştırabilirsiniz.
4. Veritabanını ayrı sorun. Dosyalar geri geldi diye veritabanının da geldiğini varsaymayın. WordPress, WooCommerce, forum ve üyelik sistemlerinde içeriğin tamamı veritabanındadır; dosyalar sadece görseller ve kodtur.

VDS ya da bulut sunucu kullanıyorsanız kurtarma şansınız daha yüksektir, çünkü sunucu seviyesinde alınan anlık görüntüler (snapshot) tüm diski kapsar. Panelinizde bir snapshot listesi varsa, geri yüklemeden önce mevcut durumun da bir snapshot’ını alın — kurtarma sırasında bir şey ters giderse başladığınız yere dönebilmelisiniz.

Kaynak 2: Hesapta ve Cihazlarınızda Duran Kopyalar#

Bu adım kulağa fazla basit gelir ama şaşırtıcı sıklıkta işe yarar. Silinen bir sitenin parçaları genellikle şu yedi yerden birinde durur:

1. Hesabın kök dizininde unutulmuş yedek arşivi. Geçmişte bir taşıma ya da güncelleme öncesi alınmış .tar.gz / .zip dosyaları çoğu zaman public_html dışında, ana dizinde durur ve silme işleminden kurtulur:

find /home/kullaniciadi -maxdepth 2 -type f \( -name "*.tar.gz" -o -name "*.zip" -o -name "*.sql" \) -exec ls -lh {} \;

2. Eski hosting hesabı. Taşıma yaptıysanız ve eskisini henüz kapatmadıysanız, en iyi kopya oradadır. Kapattıysanız bile hemen sorun; sonlandırılmış hesapların verisi bir süre daha saklanabilir.
3. Test/staging kopyası. Bir alt alan adında ya da yerel makinenizde çalışan geliştirme kopyası, üretim verisinin çok yakın bir eşidir.
4. FTP istemcinizin yerel penceresi. Uzun süredir aynı bilgisayardan çalışıyorsanız, indirilmiş dosyalar İndirilenler klasöründe ya da proje klasörünüzde durur.
5. Tasarımcı, ajans veya eski geliştirici. Tema dosyaları, görsel kaynakları ve logo genelde onlardadır; tek bir e-posta yeterlidir.
6. E-posta kutunuz. Gelen kutusunda .zip, .psd, .docx uzantılarını aratın: kurulum sırasında gönderilmiş dosya ekleri ve içerik metinleri oradadır.
7. Bulut depolama ve ortak sürücüler. İçerik ve görseller, siteye yüklenmeden önce çoğu zaman bir bulut klasöründen geçmiştir.

Bu adımda amacınız siteyi kurtarmak değil, yeniden inşa için hammadde toplamaktır. Toplayacağınız her görsel ve metin, aşağıdaki yeniden inşa aşamasında yazmayacağınız bir sayfadır.

Kaynak 3: Arşiv Siteleri ile İçerik Kurtarma#

Sunucu tarafında hiçbir şey kalmadıysa en verimli kaynak internet arşivleridir. Bu arşivler, sitenizin geçmişteki hâllerini belirli tarihlerde kaydeder ve sayfaların HTML çıktısını saklar. Yani metin içeriğinizin büyük kısmı ve sayfa yapınız oradan geri gelebilir.

Nasıl çalıştığını bilmek beklentinizi doğru kurar:

• Arşivde her sayfa yoktur. Ana sayfa sık, iç sayfalar seyrek kaydedilir; trafiği düşük bir site az arşivlenir.
• Kaydedilen şey sunucudan dönen HTML çıktısıdır, veritabanı değildir: yazı metinleri gelir, yönetici paneliniz gelmez.
• Görseller kısmen gelir, boyutlu türevleri eksik olabilir.
• Formlar, sepet, üyelik gibi dinamik işlevler gelmez.

Pratik yöntem şudur: arşiv arayüzünde alan adınızın takvim görünümünü açın, silinmeden önceki en yakın tarihi seçin ve menüdeki bağlantıları gezerek metinleri kopyalayın. Sayfa sayınız fazlaysa toplu indirmek daha hızlıdır:

wget --mirror --page-requisites --convert-links --adjust-extension \
     --no-parent --wait=2 --random-wait -e robots=off \
     -P ./arsiv-kopyasi \
     "https://web.archive.org/web/20250101000000/https://ornek.com/"

--wait=2 --random-wait parametreleri isteğe bağlı değildir: arşiv servisleri agresif indirmeyi hız sınırına takar, aradaki bekleme indirmeyi yavaşlatır ama tamamlanmasını sağlar. İndirme bittiğinde elinizde, bağlantıları yerelleştirilmiş, tarayıcıda açılabilen statik bir site kopyası olur. Bu kopya yayına almaya uygun değildir ama içeriği çıkarmak için mükemmel bir kaynaktır. İndirilen HTML dosyalarından etiketleri sıyırıp tek bir metin dosyası üretmek, içeriği yeniden girerken işinizi çok hızlandırır:

find ./arsiv-kopyasi -name "*.html" -exec sh -c \
  'echo "=== $1"; sed -e "s/<[^>]*>//g" "$1" | sed "/^\s*$/d"' _ {} \; > tum-icerik.txt

Kaynak 4: Arama Sonuçlarından Adres Haritası Çıkarma#

Arama motorlarının kendi önbelleklerini ziyaretçilere gösterme özelliği büyük ölçüde geçmişte kaldı, dolayısıyla “önbellekten sayfayı aç” beklentisiyle vakit kaybetmeyin. Ancak arama sonuçlarının hâlâ çok değerli bir işlevi var: silinen sitenin adres listesini çıkarmak.

Arama kutusuna site:ornek.com yazdığınızda, dizinde kalmış tüm sayfaların adresi, başlığı ve açıklaması listelenir. Bu üçlü size şunları verir:

• Sitenin kaç sayfadan oluştuğu ve URL yapısı — yeniden inşada aynı adresleri kullanırsanız gelen bağlantılarınızı ve sıralamanızı korursunuz.
• Her sayfanın başlığı ve meta açıklaması — bunlar zaten sayfa özetleridir.
• Hangi sayfaların arşivde aranmaya değer olduğu.

Sayfa sayısı fazlaysa listeyi elle toplamak yerine arama motoru yönetim panelinizdeki dizinlenmiş sayfalar raporunu dışa aktarın; site kaydınız orada duruyorsa silinmeden önceki tüm URL listesi tek dosya olarak iner.

⚠️ Bir uyarı: silinen sayfalar arama sonuçlarından kalıcı olmaz. Tarayıcılar sayfaların artık olmadığını fark ettikçe listeyi kısaltır. Bu yüzden URL listesini ilk günlerde dışa aktarın; bir ay sonra elinizde çok daha azı kalır.

Kaynak 5: Görseller, Sosyal Medya ve E-posta#

Metinden sonraki en büyük emek kalemi görsellerdir ve genelde en çok kaybedilen de onlardır. Aramanız gereken yerler:

• Görsel arama sonuçları. Sitenizin adıyla yapılan aramalar, görsellerinizin küçük ve orta boy kopyalarını hâlâ gösterebilir.
• Sosyal medya hesaplarınız. Paylaştığınız her bağlantı bir önizleme görseli kopyalar; ürün ve kapak görselleri çoğunlukla oradadır.
• Pazaryeri ve rehber kayıtları. Ürünlerinizi başka bir platformda da listelediyseniz görseller ve açıklamalar orada durur.
• E-posta bültenleri. Gönderdiğiniz her bülten, o dönemin ürün görsellerini ve metinlerini içerir.
• CDN kopyası. İçerik dağıtım ağı kullanıyorduysanız bazı dosyaların uç sunuculardaki kopyası bir süre daha erişilebilir kalabilir; eski görsel adresleri elinizdeyse denemeye değer.

Bu kaynaklardan gelen görseller genellikle düşük çözünürlüklüdür; ama kaybettiğiniz görselin hangisi olduğunu bilmek bile büyük kazançtır.

Veritabanı Kurtarılamadığında: Siteyi Yeniden İnşa Etmek#

Veritabanı gerçekten gittiyse ve hiçbir dökümü yoksa kabul edilmesi gereken gerçek şudur: yorumlar, üye kayıtları, sipariş geçmişi ve dinamik veri geri gelmez. Ama içerik geri gelebilir, çünkü içerik arşivlerde HTML olarak duruyordur. Sıra şöyledir:

1. Temiz kurulum yapın. Aynı alan adında, aynı yazılımla (örneğin WordPress) sıfırdan kurun. Eski kalıntıların üzerine kurmayın.
2. URL yapısını eskisiyle aynı ayarlayın. Kalıcı bağlantı (permalink) yapısını site: aramasından çıkardığınız adreslere göre seçin. Bu adım, sıralamanızı korumanın tek yoludur.
3. Sayfaları önce önem sırasına göre girin. Ana sayfa, iletişim, hizmet/ürün sayfaları, sonra en çok trafik alan içerikler. Hepsini bir günde girmeye çalışmayın.
4. Girdiğiniz sayfaları aynı adreste yayımlayın. Adresi değiştirmek zorunda kalırsanız eski adresten yenisine kalıcı yönlendirme koyun.
5. Geri getiremediğiniz adresler için karar verin. İçeriği olmayan bir adresi boş bırakmak yerine, ilgili bir sayfaya yönlendirmek ya da açıkça “bulunamadı” yanıtı vermek daha doğrudur.
6. E-ticaret verisi için ödeme sağlayıcınızın panelini kullanın. Sipariş listesi, tutarlar ve müşteri iletişim bilgileri orada durur; sipariş onay e-postalarınız da ikinci bir kaynaktır. Ürün kataloğunu ise muhasebe/stok kayıtlarınızdan yeniden kurabilirsiniz.
7. Yeniden inşa biterken yedeklemeyi kurun. Bu, sonraya bırakılacak bir madde değil, inşanın parçasıdır.

Bu süreç birkaç gün sürer ve sıkıcıdır; ama sonunda elinizde adres yapısı korunmuş, arama motorlarının tanıdığı bir site olur — yıllarca biriktirdiğiniz görünürlük kurtarılmış olur.

Bir Daha Yaşamamak İçin#

Kurtarma bittiğinde yapılacak tek doğru şey, aynı senaryonun bir daha sizi bu duruma düşürmemesini garanti etmektir. Uygulaması yarım saat süren bir kurulum yeter:

• Kopya sayısı üç, ortam sayısı iki, dışarıda bir. Sunucudaki hâli, farklı bir hizmetteki otomatik kopya, bir de kendi bilgisayarınızda ya da bulut depolamanızda duran kopya.
• Yedeğin geri yüklemesini test edin. Test edilmemiş yedek, yedek değildir. Ayda bir, yedek dosyasını indirip açabildiğinizi ve veritabanı dökümünün bozuk olmadığını doğrulayın.
• Veritabanını dosyalardan ayrı yedekleyin. Zamanlanmış bir döküm görevi, dosya yedeğinin en zayıf halkasını kapatır.
• Sağlayıcı yedeğine tek başına güvenmeyin. Nedeni ve doğru kurgusu hosting yedeği mi kendi yedeğim mi yazısında anlatılıyor.
• Saklama süresini uzun tutun. Bazı sorunlar haftalar sonra anlaşılır; yalnızca son üç günü saklayan bir kurgu o durumda işe yaramaz.

Sıkça Sorulan Sorular#

Silinen web sitesi gerçekten kurtarılabilir mi#

Evet, ancak kurtarılan şeyin ne olacağı hangi kaynağın hayatta olduğuna bağlıdır. Sağlayıcının sunucu yedeği duruyorsa site birebir geri gelir; bu en iyi senaryodur ve genellikle saatler içinde talep edilirse mümkündür. Sunucu tarafında hiçbir şey kalmadıysa dosyalar ve veritabanı geri gelmez, ancak metin içeriğin önemli kısmı arşiv kayıtlarından, adres yapısı arama sonuçlarından, görsellerin bir bölümü sosyal medya ve görsel aramalardan toparlanabilir. Yani soru “kurtarılır mı” değil, “ne kadarı kurtarılır” sorusudur.

Sağlayıcının yedeği ne kadar süre saklanır#

Saklama süresi sağlayıcıdan sağlayıcıya ve pakete göre değişir, ancak ortak nokta yedeklerin dönüşümlü olmasıdır: yeni yedek alındıkça en eskisi silinir. Bunun pratik sonucu, silinme olayından sonra beklemenin doğrudan kurtarma şansını azaltmasıdır, çünkü sıradaki yedekleme döngüsü sitenin boş hâlini kaydeder. Bu yüzden silinmeyi fark ettiğiniz anda, henüz ne olduğunu tam anlamadan bile destek talebi açmanız doğrudur. Talebinizde silinmenin yaklaşık saatini ve o saatten önceki en yakın yedeği istediğinizi açıkça yazın.

Yanlışlıkla sildiğim dosyalar sunucuda geri dönüşüm kutusuna gider mi#

Hayır, Linux tabanlı sunucularda dosya yöneticisi ya da SSH üzerinden silinen dosyalar için masaüstü işletim sistemlerindeki gibi bir geri dönüşüm kutusu yoktur. Bazı kontrol panellerinin dosya yöneticisi kendi içinde bir çöp kutusu tutabilir, dolayısıyla panelden sildiyseniz önce oraya bakmaya değer. FTP veya SSH ile silinen dosyalar ise doğrudan kaldırılır. Bu, kurtarmanın neden dosya sisteminde değil yedeklerde ve arşivlerde arandığını açıklar.

Arşiv sitelerinden sitemin tamamını geri alabilir miyim#

Hayır, arşivler sitenin tamamını değil, ziyaret edildikleri anda kaydettikleri sayfaların HTML çıktısını saklar. Ana sayfa ve popüler sayfalar sık kaydedilir, iç sayfalar seyrek; düşük trafikli sitelerde kayıt sayısı çok az olabilir. Ayrıca arşivde metin ve sayfa yapısı bulunur, veritabanınız, yönetici paneliniz, üye kayıtlarınız ve sipariş verileriniz bulunmaz. Arşivi bir yedek değil, içeriği yeniden yazmanızı önleyen bir hammadde kaynağı olarak düşünmek doğru beklentiyi kurar.

Veritabanım gitti, sipariş kayıtlarımı nasıl kurtarırım#

Sipariş verisinin en güvenilir ikinci kopyası ödeme sağlayıcınızın kendi panelidir; orada tutar, tarih ve müşteri iletişim bilgileri işlem bazında durur. İkinci kaynak, her siparişte hem müşteriye hem size giden sipariş onay e-postalarıdır; gelen kutunuzu tarayarak sipariş listesini büyük ölçüde yeniden oluşturabilirsiniz. Kargo firmanızın panelindeki gönderi kayıtları da adres bilgisi için üçüncü bir kaynaktır. Bu üç kaynağı birleştirdiğinizde muhasebe açısından eksiksiz bir tablo çıkar, ancak sitedeki sipariş geçmişi ekranını birebir geri getirmek mümkün olmaz.

Siteyi yeniden kurarken eski adresleri korumam gerekir mi#

Evet, mümkün olan her yerde eski adres yapısını korumanız gerekir, çünkü arama motorlarındaki sıralamanız ve dışarıdan aldığınız bağlantılar o adreslere bağlıdır. Adres yapısını değiştirirseniz eski bağlantılar hata sayfasına düşer ve yıllarca biriken görünürlüğü sıfırlarsınız. Bir sayfayı aynı adreste yeniden yayımlayamıyorsanız, en yakın ilgili sayfaya kalıcı yönlendirme koymak ikinci en iyi çözümdür. Bu yüzden yeniden inşaya başlamadan önce eski adres listesini çıkarmak, ilk yapılacak işlerdendir.

VDS sunucuda silinen dosyalar için ne yapabilirim#

VDS ya da bulut sunucuda ilk bakılacak yer sağlayıcının anlık görüntü (snapshot) listesidir; sunucu seviyesindeki bu görüntüler tüm diski kapsadığı için geri yükleme çok daha eksiksiz olur. Snapshot yoksa, dosya sistemi seviyesinde kurtarma araçları teorik olarak bir şans sunar, ancak bunun ön koşulu diske hiç yazmamış olmaktır; sunucu çalışmaya devam ediyorsa şans hızla azalır. Bu yüzden fark ettiğiniz anda ilgili servisleri durdurmak, kurtarma ihtimalini korumanın en etkili adımıdır. Geri yükleme yapmadan önce mevcut durumun da bir snapshot’ını almayı unutmayın.

Hosting hesabımı iptal ettim, verim hâlâ duruyor olabilir mi#

Muhtemelen evet, ama bu tamamen zamana bağlıdır. İptal edilen hesaplar çoğu sağlayıcıda hemen silinmez; önce askıya alınır ve bir süre saklandıktan sonra kalıcı olarak kaldırılır. Bu süre içinde destek ekibine ulaşıp verinin hâlâ diskte olup olmadığını sorarsanız çoğu zaman bir dışa aktarma alabilirsiniz. Bekledikçe şans azaldığı için, iptalin üzerinden ne kadar geçmiş olursa olsun sormaktan zarar gelmez — ama bugün sormak, yarın sormaktan her zaman daha iyidir.

Kapanış#

“Yedeğim yok” cümlesi bir sonuç bildirmez, sadece kolay yolun kapalı olduğunu söyler. Elinizde hâlâ dört farklı kaynak vardır: sağlayıcının dönüşümlü sunucu yedeği, hesabınızda ve cihazlarınızda dağınık duran kopyalar, arşiv kayıtlarındaki HTML içerik ve arama sonuçlarından çıkarılan adres haritası. Bunların içinde tek zamana duyarlı olanı birincisidir — bu yüzden silinmeyi fark ettiğiniz dakikada, henüz ne olduğunu tam anlamadan önce destek talebini açın ve “sonraki yedekleme döngüsü boş hâli kaydetmeden” işlem yapılmasını isteyin. Diğer üç kaynak sizi bekler, o beklemez. Veritabanı gerçekten kurtarılamasa bile içeriğin yeniden inşası mümkündür ve eski adres yapısını koruyarak yaptığınızda kaybettiğiniz görünürlüğün büyük kısmını geri alırsınız.

Bu deneyimden sonra tek doğru yatırım, aynı senaryoyu bir daha imkânsız kılmaktır. Otomatik ve saklama süresi uzun bir kurgu için yedekleme çözümlerimize, kaynakları size ayrılmış ve anlık görüntü alabileceğiniz bir yapı için VDS sunucu paketlerine bakabilirsiniz. Siteyi yeniden inşa etmek yerine mevcut kopyayı sağlıklı bir ortama taşımak istiyorsanız site taşıma hizmeti bu işi üstlenir; sıfırdan sağlam bir kurulumla başlamak isteyenler için de hosting paketleri doğru başlangıç noktasıdır.