Web Sitesi Yedekten Güvenle Nasıl Geri Yüklenir
Yayınlanma tarihi: 9 Eylül 2026
Bir eklenti güncellemesi başarısız olur, bir tema değişikliği düzeni bozar ya da silinen bir veritabanı tablosu çalışan bir siteyi bir anda hata sayfasına dönüştürür. Böyle bir durumda, geri dönmenin en hızlı yolu genellikle web sitesini yedekten geri yüklemektir. Ama hız, tahmin yürütmek anlamına gelmemelidir. Dikkatsiz bir geri yükleme, yedekte hiç bulunmayan daha yeni siparişlerin, form gönderimlerinin, e-postaların veya içeriklerin üzerine yazabilir.
İyi haber şu ki kurtarma işleminin, terminal penceresi ve fazla kahveyle geçen uzun bir geceye dönüşmesi gerekmez. Doğru yedek, net bir kurtarma noktası ve canlıya almadan önce yapılacak birkaç kontrolle, ikinci bir sorun yaratmadan bir web sitesini geri getirebilirsiniz.
Web Sitesini Yedekten Geri Yüklemeden Önce
İşe gerçekten neyin başarısız olduğunu belirleyerek başlayın. Tüm site mi kapalı, yoksa sorun çıkaran tek bir sayfa, eklenti, veritabanı tablosu veya yapılandırma dosyası mı var? Tam geri yükleme, web sitesi ele geçirildiğinde, ciddi şekilde bozulduğunda veya birçok yerde değiştirildiğinde faydalıdır. Bu, tek bir bozuk ayara verilecek doğru yanıt her zaman değildir.
Sonraki adımda, kurtarma noktasını dikkatle seçin. En yeni yedek otomatik olarak en iyi seçenek değildir. Sorun, zamanlanmış bir yedek çalıştıktan sonra başladıysa, o yedek zaten sorunu içeriyor olabilir. Zaman damgalarına bakın ve bunları sitenin en son düzgün çalıştığı bilinen zamanla eşleştirin.
Herhangi bir şeyi değiştirmeden önce, mevcut durumun yeni bir yedeğini veya anlık görüntüsünü alın. Evet, mevcut durum bozuk görünse bile. Bu durum; yakın tarihli müşteri siparişlerini, yüklenen dosyaları, veritabanı kayıtlarını veya sorunun teşhis edilmesine yardımcı olacak ipuçlarını içerebilir. Bu, seçilen geri yükleme noktasının beklenenden daha eski ya da eksik olması durumunda size geri dönüş yolu sağlar.
Yedeğin neleri içerdiğini de bilmelisiniz. Kullanılabilir bir web sitesi yedeği; site dosyalarını, veritabanlarını, e-posta verilerini, sunucu yapılandırmasını, SSL ile ilgili ayarları veya bunların yalnızca bir kısmını içerebilir. Web sitesi dosyalarını eşleşen veritabanı olmadan geri yüklemek, WordPress'i, e-ticaret platformlarını ve özel uygulamaları çoğu zaman tutarsız bir durumda bırakır.
Tam mı Kısmi mi Geri Yükleme Yapacağınıza Karar Verin
Tam geri yükleme, web sitesi dosyalarını ve veritabanını önceki bir yedeğin içeriğiyle değiştirir. Bu, büyük bir arıza, kötü amaçlı yazılım temizliği, yanlışlıkla hesap silinmesi veya başarısız bir taşıma işleminden sonra en temiz seçenektir. Bunun karşılığında veri kaybı riski vardır: ayrı olarak dışa aktarmaz veya kurtarmazsanız, bu yedekten sonra oluşturulan her şey kaybolabilir.
Kısmi geri yükleme daha hassastır. Eksik bir uploads klasörünü geri yükleyebilir, hasarlı bir tema dosyasını değiştirebilir, bir veritabanı tablosunu içe aktarabilir veya bir eklenti dizinini geri alabilirsiniz. Bu yaklaşım daha yeni içerikleri ve işlemleri korur, ancak arızanın kaynağı konusunda daha fazla güven gerektirir.
Örneğin, bir site bir WordPress eklentisi güncellemesinden hemen sonra kullanılamaz hâle geldiyse, tüm sunucuyu geri yüklemek gereksiz olabilir. Bu eklentiyi devre dışı bırakmak veya değiştirmek yeterli olabilir. Bir veritabanının üzerine yazıldıysa veya site bir saldırgan tarafından değiştirildiyse, temiz olduğu bilinen bir yedekten tam geri yükleme yapmak genellikle daha güvenlidir.
Siteyi Güvenli Bir Kurtarma Durumuna Alın
Site hâlâ herkese açık şekilde erişilebiliyor ancak öngörülemez davranıyorsa, geri yüklemeden önce bakım modunu etkinleştirin. Bu, dosyalar ve veritabanı kayıtları arka planda değişirken ziyaretçilerin sipariş vermesini, form göndermesini veya hesapları düzenlemesini önler.
Mağazalar ve üyelik siteleri için, yedek zamanından sonra gerçekleşen etkinliği kaydedin. Mümkünse yakın tarihli siparişleri, müşteri kayıtlarını, destek taleplerini ve gönderimleri dışa aktarın. Bu kayıtlar, kurtarma sonrasında yeniden girilebilir veya içe aktarılabilir. Bu adımı atlamak, teknik bir olayı müşteri hizmetleri sorununa dönüştürebilir.
Ayrıca, geri yükleme sırasında yeni veri yazabilecek zamanlanmış görevleri duraklatın. Cron görevleri, envanter senkronizasyonları, bülten otomasyonu, ödeme webhooks'ları ve önbellekleme hizmetleri kurtarma sürecini daha da karmaşık hâle getirebilir. Tüm sunucuyu devre dışı bırakmanız gerekmez. Sadece etkilenen web sitesine bağlı süreçleri, site yeniden kararlı hâle gelene kadar durdurun.
Dosyaları ve Veritabanını Birlikte Geri Yükleyin
Bir hosting kontrol panelinde, yedek tarihini bularak ve kurtarmanız gereken web sitesini veya hesabı seçerek başlayın. Hedefi dikkatle doğrulayın. Birden fazla etki alanı veya müşteri hesabı bulunan bir sunucuda, yanlış document root konumuna geri yükleme yapmak kolay yapılan ama sonucu çok can sıkıcı olan bir hatadır.
Paneliniz dosyaları ve veritabanlarını ayrı işlemler olarak ele alıyorsa önce web sitesi dosyalarını geri yükleyin. Bu normalde document root'u, uygulama kodunu, medya yüklemelerini ve .htaccess gibi gizli dosyaları içerir. Gizli dosyalar önemlidir çünkü çoğu zaman yönlendirmeleri, yeniden yazma kurallarını, erişim kontrollerini ve uygulama ayarlarını içerirler.
Ardından eşleşen veritabanını geri yükleyin. Birçok içerik yönetim sistemi için veritabanı, dosyaların çalışmasını sağlayan yazıları, sayfaları, kullanıcıları, ayarları, mağaza siparişlerini ve eklenti yapılandırmalarını barındırır. Geri yüklenen yapılandırma dosyasındaki veritabanı kimlik bilgilerini kullanın, ardından uygulamanın hedeflenen veritabanı adına, kullanıcıya ve ana makineye işaret ettiğini doğrulayın.
Bir veritabanını manuel olarak içe aktarmanız gerekiyorsa, herhangi bir şeyi değiştirmeden önce tablo önekini kontrol edin. Bir WordPress kurulumu aynı veritabanında birden fazla tablo kümesine sahip olabilir. Doğru yedeği yanlış öneke içe aktarmak, sitenin hiç değişmemiş, kısmen geri yüklenmiş veya garip şekilde karışmış görünmesine neden olabilir.
FASTPANEL, web sitesi, veritabanı ve sunucu yönetimini tek ve net bir çalışma alanında bir araya getirir; bu da, geri yüklemeyi uygulamadan önce nereye ait olduğunu doğrulamayı kolaylaştırır. Amaç teknik ayrıntıları gizlemek değildir. Amaç, önemli olanları gerçekten kullanabileceğiniz yere koymaktır.
Siteyi Açmadan Önce Yapılandırmayı Kontrol Edin
Bir geri yükleme, iyi parçalarla birlikte eski ayarları da geri getirebilir. Veritabanı kimlik bilgileri, uygulama URL'leri, önbellek ayarları ve ortam değişkenleri için yapılandırma dosyalarını gözden geçirin. Bu özellikle bir taşıma, sunucu değişikliği veya etki alanı değişiminden sonra önemlidir.
Etki alanının hâlâ doğru sunucuya çözümlendiğini doğrulayın. DNS kayıtları genellikle bir web sitesi yedeği tarafından değiştirilmez, ancak geri yüklenen bir yapılandırma ziyaretçileri eski bir etki alanına, hazırlık adresine veya güvenli olmayan bir URL'ye yönlendirebilir. Siteniz yönlendirmeler kullanıyorsa hem www'li sürümü hem de www'suz sürümü kontrol edin.
SSL'yi kontrol etmeye de değer. Geri yüklenen bir virtual host yapılandırması eski bir sertifika yoluna başvurabilir veya daha yeni bir etki alanı takma adını atlayabilir. Tarayıcı kurtarma sonrasında sertifika uyarısı gösterirse bunu görmezden gelmeyin ve ziyaretçilerden de görmezden gelmelerini istemeyin. Siteyi yeniden açmadan önce sertifikayı ve yönlendirme kurallarını düzeltin.
Ziyaretçileri Geri Göndermeden Önce Test Edin
Başarılı bir geri yükleme mesajını, web sitesinin sağlıklı olduğunun kanıtı olarak görmeyin. Bu yalnızca panelin işlemi tamamladığını doğrular. Siteyi özel bir tarayıcı penceresinde açın, ardından işletmeniz için en önemli sayfaları ve işlemleri test edin.
Standart bir kurumsal site için ana sayfayı, iletişim formunu, gezinmeyi, medya dosyalarını ve korumalı giriş alanlarını kontrol edin. Bir çevrimiçi mağaza için ürün sayfalarını, sepeti, ödeme akışını, işlemsel e-postayı ve ödeme entegrasyonunu gereksiz canlı siparişler vermeden test edin. Müşteri sitelerini yöneten bir ajans için, tek bir hesap düzeyindeki geri yüklemenin her şeyi düzelttiğini varsaymak yerine etkilenen her etki alanını ayrı ayrı doğrulayın.
Hatalar devam ediyorsa sunucu günlüklerini ve uygulama günlüklerini inceleyin. Geri yükleme sonrası bir 500 hatası; yanlış dosya izinleri, desteklenmeyen bir PHP sürümü, eksik bir uzantı veya önbelleğe alınmış yapılandırmadan kaynaklanabilir. Bir veritabanı bağlantı hatası genellikle kimlik bilgilerine, veritabanı kullanılabilirliğine veya beklendiği gibi geri yüklenmemiş bir yapılandırma dosyasına işaret eder.
Temel site çalıştıktan sonra uygulama önbelleğini ve sunucu tarafındaki ya da CDN önbelleğini temizleyin. Aksi takdirde, geri yüklenen site sağlıklı olsa bile ziyaretçiler eski sayfaları veya eski hata yanıtlarını görebilir.
Yedek Daha Eskiyse Son Verileri Kurtarın
Yedek önemli değişikliklerden daha eskiyse, kurtarmanın iki bölümü vardır: kararlı web sitesini geri yükleyin, ardından hâlâ ihtiyaç duyduğunuz daha yeni kayıtları geri getirin. Bu; yakın tarihli siparişleri içe aktarmak, makaleleri yeniden oluşturmak, yüklenen belgeleri geri yüklemek veya yedek alındıktan sonra yapılandırılmış entegrasyonları yeniden bağlamak anlamına gelebilir.
Seçici olun. Daha yeni bir veritabanı dökümünün tamamını içe aktarmak, en başta geri yüklemeyi zorunlu kılan aynı bozuk ayarı, kötü amaçlı yazılımı veya bozulmayı yeniden ortaya çıkarabilir. İhtiyaç duyduğunuz verileri arızaya neden olan verilerle karşılaştırın, ardından yalnızca tutulması güvenli kayıtları taşıyın.
İşte bu yüzden sık yedekler önemlidir, özellikle e-ticaret siteleri ve aktif üyelik platformları için. Ayda bir değişen tanıtım amaçlı bir site için günlük yedek yeterli olabilir. Yoğun bir mağaza daha sık veritabanı yedeklerine, ayrı sunucu dışı depolamaya ve yakın tarihli işlemleri kurtarmak için belgelenmiş bir yönteme ihtiyaç duyabilir.
Bir Sonraki Geri Yüklemeyi Daha Az Stresli Hâle Getirin
En iyi yedek, baskı altında bulabileceğiniz, anlayabileceğiniz ve geri yükleyebileceğiniz yedektir. Yedekleri bir takvime göre alın, birden fazla kurtarma noktası tutun ve en az bir kopyayı üretim sunucusundan uzakta saklayın. Sunucunun kendisi arızalanırsa, yalnızca o sunucuda depolanan bir yedek pek yardımcı olamaz.
Zaman zaman bir hazırlık ortamında geri yüklemeyi test edin. Bu, yedeğin eksiksiz olduğunu doğrular ve kurtarmanın gerçekte ne kadar sürdüğünü ölçmenizi sağlar. Ayrıca, bunlar acil duruma dönüşmeden önce eksik dosyaları, unutulmuş veritabanlarını ve izin sorunlarını ortaya çıkarır.
Bir geri yükleme planının karmaşık olması gerekmez. Yedeklerin nerede bulunduğunu, siteyi hangi hizmetlerin çalıştırdığını, kimlerin erişimi olduğunu ve kurtarmadan sonra nelerin kontrol edilmesi gerektiğini kaydedin. Bir şey bozulduğunda, bu küçük hazırlık miktarı paniği yönetilebilir adımlar dizisine dönüştürür.
Bir web sitesi yedeği yalnızca eski dosyaların bir kopyası değildir. Bu, kararlı bir nokta seçmek, sonrasında değişenleri korumak ve siteyi güvenle yeniden çalışır hâle getirmek için pratik yolunuzdur.