Site Yedeğini Geri Yükleme: Hatasız ve Pratik Rehber

Site açılmıyor, ya beyaz sayfa görünüyor ya da eksik bir güncellemeden sonra her şey karışmış. Çoğu yöneticinin yaptığı ilk şey, dünkü tam yedeği bugünkü sitenin üzerine yazmaktır. Bu, vakaların yarısında durumu daha da kötüleştirir. Yedek geri yükleme cerrahi bir işlemdir, büyük bir kopyala-yapıştır değil. Herhangi bir komuttan önce tam olarak neyin bozulduğunu ve neyin sağlam olduğunu bilmelisiniz.

Önce teşhis et, sonra geri yükle

Yedek dosyalarına dokunmadan önce üç şeyi kontrol edin. Birincisi, PHP hata günlüğüne bakın; hata belirli bir eklentiden veya dosyadan geliyorsa, tüm siteyi kurtarmaya gerek yoktur. İkincisi, veritabanının yanıt verip vermediğine bakın. Üçüncüsü, sorunun DNS veya sunucudan mı yoksa kodun kendisinden mi kaynaklandığını kontrol edin. Alan adı yanlış IP'ye işaret ediyorsa, hiçbir yedek sorunu çözmez. Bu aşama için DNS ve ağ kontrolü kullanabilir ve sorunun içerikten değil çözümlemeden kaynaklandığından emin olabilirsiniz.

Basit bir test: içeriği <?php echo "ok"; olan bir test.php dosyası oluşturun ve tarayıcıda açın. "ok" görürseniz, web sunucusu ve PHP sağlıklıdır ve sorun uygulamadadır. 500 alırsanız, sorun sunucu tarafında veya yapılandırmadadır. Beyaz sayfa ise, muhtemelen görüntülenmeyen bir PHP hatanız var.

Tam kurtarma ile kısmi kurtarma karşılaştırması

Tam kurtarma, tüm dosyaları ve tüm veritabanını belirli bir zaman noktasına döndürmek anlamına gelir. Bu yalnızca üç durumda mantıklıdır: sitenin hacklenmesi, veritabanı bozulması veya yeni bir sunucuya taşınma. Diğer durumlarda, kısmi kurtarma hem daha hızlıdır hem de daha az risk taşır.

Yukarıdaki tabloda süre sütununun site boyutuna bağlı olduğuna dikkat edin. 500 megabaytlık bir site ve 200 megabaytlık bir veritabanı, normal bir paylaşımlı hosting'de tam kurtarma bir saatten fazla sürebilir, çünkü hem yükleme hem de dosyaları çıkarma zaman alır.

Veritabanı geri yükleme: komutlar ve pratik ipuçları

Veritabanı yedek dosyanız olduğunu varsayalım: mysqldump ile alınmış backup.sql. Bunu SSH komut satırından geri yüklemek için:

mysql -u dbuser -p dbname < backup.sql

Dosya gzip ile sıkıştırılmışsa, önce açın veya doğrudan mysql'e verin:

gunzip < backup.sql.gz | mysql -u dbuser -p dbname

Çoğu kişinin bilmediği bir nokta: yedeği mysqldump --single-transaction ile aldıysanız, çıktı dosyası --add-drop-table da eklemediğiniz sürece DROP TABLE IF EXISTS içermez. Yani dosyayı mevcut veritabanının üzerine yazdığınızda, mevcut tablolar dokunulmadan kalır ve yalnızca kayıtlar eklenir. Sonuç olarak, kurtarma sonrasında sitenizde her yazının iki kopyası olur. Veritabanının tamamen değiştirilmesini istiyorsanız, önce onu boşaltın:

mysql -u dbuser -p -e "DROP DATABASE dbname; CREATE DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

Sonra dosyayı içe aktarın. Burada hata yapılıyor: çoğu kişi veritabanını boşaltmadan yedeği üzerine yazıyor ve yinelenen kayıtları gördükten sonra yedeğin bozuk olduğunu düşünüyor. Aslında yedek sağlamdı, hedef veritabanı hazır değildi.

Yalnızca bir tabloyu kurtarma

Yalnızca bir tablo bozulduysa, tüm veritabanını geri yüklemenize gerek yoktur. SQL dosyasından yalnızca o tabloyla ilgili bölümü çıkarabilirsiniz. Bu, sed veya awk ile yapılabilir, ancak daha basit olanı phpMyAdmin gibi bir araçla tabloyu seçip içe aktarmaktır. Yedek dosyası büyükse (50 megabayttan fazla), phpMyAdmin genellikle zaman aşımına uğrar. Bu durumda komut satırını kullanın veya dosyayı parçalara ayırın.

Dosyaları geri yükleme: neyi saklamalıyız

public_html klasörünü yedekle değiştirmeden önce şunları ayırın:

• Mevcut wp-config.php, çünkü veritabanı bilgileri veya güvenlik anahtarları değişmiş olabilir.
• Yedek tarihinden daha yeni dosyalarınız varsa uploads klasörü.
• İçinde yönlendirmeler veya özel ayarlar varsa .htaccess dosyası.
• Yedek tarihinden sonra bir eklenti kurduysanız wp-content/plugins klasörü.

Değiştirdikten sonra dosya izinlerini düzeltin. Yanlış izinler, kurtarma sonrası 403 hatasının yaygın nedenlerinden biridir:

find /home/user/public_html -type d -exec chmod 755 {} \;
find /home/user/public_html -type f -exec chmod 644 {} \;

Site paylaşımlı hosting'deyse, dosya sayısı da önemlidir. Binlerce fazla dosya içeren eski bir yedeği geri yüklemek, sizi inode sınırına yaklaştırabilir. Geri yüklemeden önce mevcut ve yedek dosya sayısını sayın. Hosting'de inode sınırı rehberi, bu sayıyı neyin tükettiğini ve nasıl sayılacağını açıklar.

Geri yüklemeden önce şu üç şeyi yapın

1. Mevcut durumdan yedek alın, bozuk olsa bile. Daha sonra belirli bir dosyaya ihtiyaç duyabilirsiniz.
2. Siteyi bakım moduna alın ki kullanıcılar kurtarma sırasında hatayla karşılaşmasın.
3. Yeterli disk alanınız olduğundan emin olun. 1 gigabayt boş alanı olan bir hosting'de 2 gigabaytlık bir yedeği açmak, iş ortasında durur.

Üçüncü noktayı ciddiye alın. Dosya çıkarma sırasında No space left on device hatası, siteyi olası en kötü durum olan yarı kurtarılmış halde bırakır. Yeterli alanınız yoksa, önce günlükler ve önbellekler gibi gereksiz dosyaları silin.

Panelden mi yoksa komut satırından mı kurtarma seçimi

Yedek 100 megabayttan küçükse ve veritabanı küçükse, hosting panelini kullanın. Daha hızlıdır ve komut hatası riski yoktur. Yedek daha büyükse, yalnızca bir tabloyu geri yüklemeniz gerekiyorsa veya site özel bir sunucudaysa, komut satırı daha iyi bir seçimdir. Komut satırında tam kontrole sahipsiniz ve iş ortasında durdurabilir veya yalnızca bir bölümü kurtarabilirsiniz.

Az söylenen pratik bir sınırlama: paylaşımlı hosting'de kurtarma işleminin kendisi kaynak tüketir. Kurtarma uzarsa, Entry Process sınırına çarpabilirsiniz ve işlem ortasında kill edilebilir. Bunu Entry Process açıklamasında ayrıntılı olarak görebilirsiniz. Böyle bir durumda, kurtarmayı düşük trafikli saatlerde yapın veya siteyi geçici olarak erişimden çıkarın.

Siteniz Linux hosting üzerindeyse ve büyük bir yedeğiniz varsa, dosyayı tarayıcı üzerinden değil doğrudan wget veya scp ile sunucuya koymak daha iyidir. Tarayıcıdan yükleme, 100 megabayt üzeri dosyalar için genellikle kesilir.

Kurtarma sonrası neyi kontrol etmeliyiz

Kurtarma bittiğinde, siteyi açıp "tamam, düzeldi" demeyin. Şunları kontrol edin:

• Ana sayfa, bir yazı ve bir sabit sayfa doğru açılıyor mu?
• İletişim formu çalışıyor mu? (Bazı eklentilerin ayarları veritabanındadır ve eski olabilir.)
• İç bağlantılar mevcut dosyalara işaret ediyor mu?
• SSL hâlâ etkin mi? Yedek eskiyse, .htaccess içinde HTTPS yönlendirmesi olmayabilir.
• Önbellek temizlendi mi? Eski önbellek sayfaların önceki sürümünü gösterebilir ve kurtarılmadığını düşünürsünüz.

WordPress kullanıyorsanız, veritabanı kurtarmasından sonra wp_options tablosundaki site adresini kontrol edin. Yedek başka bir alan adından alınmışsa, adresler yanlış olacak ve site eski alan adına yönlendirecektir. Bunu basit bir sorguyla görebilirsiniz:

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');

Değer yanlışsa, UPDATE ile düzeltin. Burada hata yapılıyor: çoğu kişi sorunun DNS'ten olduğunu düşünüp nameserver'ları değiştirmeye başlar, oysa sorun veritabanındaki tek bir kayıttır. Sorunun DNS'ten mi yoksa veritabanından mı olduğundan emin değilseniz, önce DNS'i kontrol edin. Alan adını hosting'e bağlama rehberi, nameserver ile A kaydı arasındaki farkı açıklar ve bu ikisini ayırmanıza yardımcı olur.

Sık sorulan sorular

Yalnızca veritabanını geri yükleyip dosyalara dokunmamak mümkün mü?

Evet ve birçok durumda bu daha doğrudur. Sorun içerik veya veritabanı ayarlarındaysa ve site dosyaları sağlamsa, yalnızca veritabanını geri yükleyin. Ancak bir eklentiyi güncellediyseniz ve tablo yapısı değiştiyse, eski veritabanını geri yüklemenin uyumsuzluk yaratabileceğini unutmayın.

Yedek geri yüklendikten sonra site neden hâlâ hata veriyor?

Üç yaygın neden: tarayıcı veya sunucu önbelleği temizlenmemiş, dosya izinleri çıkarma sonrası değişmiş veya PHP sürümü geri yüklenen kodla uyumlu değil. Yedek PHP 7.4'lü bir sunucudan alınmışsa ve mevcut sunucu PHP 8.2 ise, eski kod hata verebilir. Ayarları kontrol etmek için php.ini ayarları referansına bakın.

Geri yüklemesi kolay olacak şekilde yedeği hangi komutla almalıyım?

MySQL veritabanı için mysqldump -u user -p --single-transaction --routines --triggers dbname > backup.sql komutu gerekli seçenekleri kapsar. Dosyalar için tar -czf backup.tar.gz public_html yeterlidir. Yedeğin kısmi geri yüklenebilir olmasını istiyorsanız, büyük bir tar dosyası yerine klasörleri ayrı tutun.

Tam kurtarma ne kadar sürer?

Yedek boyutuna, disk hızına ve hosting türüne bağlıdır. Normal diskli bir paylaşımlı hosting'de her gigabayt dosya yaklaşık 5 ila 15 dakika sürer. NVMe'li bir sunucuda bu sayı her gigabayt için 2 dakikanın altına iner. Zaman önemliyse, kurtarmayı düşük trafikli saatlerde yapın ve önceden disk alanını kontrol edin.

Her kurtarmadan önce mevcut durumdan bir yedek alın. Hata yaparsanız sizi kurtaracak tek şey budur.