Bir site paylaşımlı hostingden VPS'e nasıl taşınır
Taşımanın kendisi birkaç saat sürer; hatalar ise genellikle onun etrafında olur: unutulmuş bir cron görevi, nginx'in okumadığı .htaccess kuralları, eski adresi gösteren bir AAAA kaydı veya IP değişikliğiyle birlikte kaybolan e-posta. Aşağıda PHP ve MySQL ile çalışan bir site için komutları ve kontrolleriyle birlikte adımların sırası var.
Bu yazı nasıl taşınılacağıyla ilgili. Taşınmaya değip değmeyeceği ve hangi sunucunun alınacağı Paylaşımlı hostingden VPS'e ne zaman geçilmeli yazısında ele alınıyor. Burada VPS'in zaten satın alındığını, sitenin ise WordPress, Bitrix, Laravel veya MySQL veritabanlı başka bir PHP motoruyla yapıldığını varsayıyoruz. Diğer yığınlar için sıra aynıdır, yalnızca komutlar değişir.
Zamanlama: dört aşamada taşınma
- İki gün önce: hostingde çalışan her şeyi not edin ve DNS kayıtlarının TTL değerini düşürün.
- Bir gün önce: sunucuyu hazırlayın, dosyaları ve veritabanını kopyalayın, siteyi yeni adreste test edin.
- Taşınma günü: siteyi yazmaya kapatın, güncel verileri aktarın, DNS'i değiştirin.
- Sonraki bir iki hafta: hostingi yedek seçenek olarak açık tutun.
Hostingde nelerin not edilmesi gerekir
Taşınmadan sonraki sorunların neredeyse tamamı, hostingde kendiliğinden çalışan ve unutulan şeylerdir. Hosting panelini gözden geçirin ve şunları not edin:
- PHP sürümü ve eklentileri. Bunlar panelde veya SSH üzerinden
php -vvephp -mkomutlarıyla görülebilir. VPS'e aynı sürümü kurun, PHP güncellemesini ise daha sonra ayrıca yapın. - Veritabanının sürümü ve boyutu, tabloların karakter kodlaması.
- Cron görevleri: neyin ne sıklıkla çalıştığı. VPS'te dosya yolları farklı olacaktır.
- .htaccess kuralları: yönlendirmeler, okunabilir URL'ler, klasörlere erişim kısıtlamaları.
- E-posta: posta kutuları, yönlendirmeler, MX kayıtlarının nereyi gösterdiği.
- Alt alan adları ve tüm DNS kayıtları, hizmet doğrulamaları için TXT kayıtları dahil.
- Sitenin IP adresini bilen harici hizmetler. Ödeme sistemleri, 1C ile veri alışverişi, iş ortaklarının API'leri ve e-posta hizmetleri çoğu zaman yalnızca izin verilen adreslerden gelen isteklere izin verir. Yeni IP'nin bunlara önceden eklenmesi gerekir.
Taşınmadan bir iki gün önce alan adının A ve AAAA kayıtlarının TTL değerini 300 saniyeye düşürün. Böylece geçiş günü yeni adres bir gün içinde değil, dakikalar içinde yayılır.
Sunucuyu hazırlayın
Temel korumayla başlayın: güncellemeler, anahtarla giriş, güvenlik duvarı. Bunların hepsi VPS satın aldıktan sonra ilk 10 adım: güvenlik yazısında toplandı. Sonrasında iki yol var.
Kontrol paneliyle. ISPmanager, FASTPANEL veya aaPanel web sunucusunu, doğru PHP sürümünü ve veritabanını birkaç tıklamayla kurar ve hostingden alışık olduğunuz bir arayüz sunar. Bu panellerle gelen paketler: ISPmanager'lı VPS, FASTPANEL'li VPS, aaPanel'li VPS.
Panelsiz. Ubuntu ve Debian için asgari set tek bir komutla kurulur; sürüm numarası olmayan paketler sistemle birlikte gelen PHP'yi getirir:
apt install nginx mariadb-server php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip php-intl
Hostingde sistemdekinden daha eski veya daha yeni bir PHP sürümü varsa, o sürüm Ubuntu ve Debian için PHP paketleri sunan üçüncü taraf depolardan kurulur.
Hostingden temel farkı göz önünde bulundurun: nginx .htaccess dosyasını okumaz. Yönlendirmeleri ve okunabilir URL kurallarını sitenin yapılandırmasına taşımak gerekir. WordPress için temel kural şöyledir: try_files $uri $uri/ /index.php?$args;. Kural çoksa nginx'in arkasına Apache koymak daha kolaydır: çoğu panel böyle çalışır ve .htaccess geçerli olmaya devam eder.
Dosyaları taşıyın
Hostingde SSH erişimi varsa en hızlısı dosyaları doğrudan VPS'ten rsync ile çekmektir:
rsync -avz user@old-host.example:~/public_html/ /var/www/example.com/
Aynı komutu tekrar çalıştırmak yalnızca değişenleri aktarır; bu, taşınma günü işe yarayacak. SSH yoksa iki seçenek var: panelin dosya yöneticisinde bir arşiv oluşturup onu wget ile sunucuya indirmek ya da dosyaları lftp aracıyla FTP üzerinden çekmek:
lftp -u user old-host.example -e "mirror --parallel=4 public_html /var/www/example.com; quit"
Sıradan FTP parolayı açık metin olarak iletir, bu yüzden hosting SFTP veya FTPS destekliyorsa onları kullanın. Kopyalamadan sonra dosyaları web sunucusu kullanıcısına verin ve olağan izinleri ayarlayın:
chown -R www-data:www-data /var/www/example.com
find /var/www/example.com -type d -exec chmod 755 {} +
find /var/www/example.com -type f -exec chmod 644 {} +
Veritabanını taşıyın
Hostingde bir döküm alın. SSH üzerinden:
mysqldump --single-transaction --default-character-set=utf8mb4 -u user -p dbname | gzip > db.sql.gz
SSH yoksa döküm phpMyAdmin üzerinden dışa aktarılır, ancak hostingdeki zaman sınırı nedeniyle büyük veritabanlarında başarısız olabilir; bu durumda dökümü destek ekibinden isteyin veya parça parça alın. VPS'te veritabanını ve kullanıcıyı oluşturun ve dökümü yükleyin:
mysql -e "CREATE DATABASE site CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'site'@'localhost' IDENTIFIED BY 'guclu_parola';
GRANT ALL PRIVILEGES ON site.* TO 'site'@'localhost';"
zcat db.sql.gz | mysql site
Yükleme sırasında sık görülen bir hata Unknown collation: 'utf8mb4_0900_ai_ci' hatasıdır. Bu, dökümün MySQL 8'de alındığı, VPS'te ise bu sıralama düzenini tanımayan MariaDB'nin kurulu olduğu anlamına gelir. Ya VPS'e hostingdekiyle aynı veritabanı yönetim sistemini kurun ya da dökümdeki sıralama düzenini utf8mb4_unicode_ci ile değiştirin.
Ardından yeni veritabanı erişim bilgilerini sitenin ayarlarına yazın: WordPress için wp-config.php, Bitrix için /bitrix/.settings.php ve /bitrix/php_interface/dbconn.php, Laravel için .env dosyası. Veritabanı sunucusu artık localhost'tur.
Cron görevlerini taşıyın
Görevleri root olarak değil, sitenin kullanıcısıyla çalıştırın: crontab -u www-data -e. Yolları kontrol edin: hostingde site /home/user/public_html gibi bir yerdeydi, VPS'te ise /var/www/example.com içinde; PHP'nin yolu da farklı olabilir (which php). Hostingin kendisinin yürüttüğü görevleri ayrıca kontrol edin: cron üzerinde çalışan Bitrix ajanları, 1C ile veri alışverişi, kuyruktaki e-postaların gönderilmesi.
Siteyi DNS'i değiştirmeden önce test edin
Ziyaretçiler hâlâ hostinge gidiyor, siz ise yeni sunucuyu kendi bilgisayarınızda açabilirsiniz. Alan adını sunucunun IP'siyle birlikte bilgisayarınızın hosts dosyasına yazın (Linux ve macOS'ta /etc/hosts, Windows'ta C:\Windows\System32\drivers\etc\hosts):
203.0.113.10 example.com www.example.com
Ana sayfayı, kataloğu, ürün sayfasını, aramayı, formları, sepeti ve yönetim paneline girişi gözden geçirin, bir resim yükleyin. Bu sırada hata logunu izleyin: tail -f /var/log/nginx/error.log. Sunucunun yanıtını tarayıcı olmadan hızlıca şöyle kontrol edebilirsiniz: curl -I --resolve example.com:80:203.0.113.10 http://example.com/.
Bu adımdaki tipik sorunlar:
- 502 Bad Gateway: nginx PHP-FPM'i göremiyor; sitenin yapılandırmasındaki soket yolu, PHP havuzu ayarlarındakiyle eşleşmiyor.
- Beyaz ekran veya 500 hatası: bir PHP eklentisi eksik. Tam adı hata logunda yer alır.
- Büyük dosyalar yüklenmiyor: nginx'te istek gövdesi varsayılan olarak 1 MB ile sınırlıdır (
client_max_body_size), PHP'de iseupload_max_filesizevepost_max_sizeparametreleriyle. - Bağlantılar 404'e gidiyor: .htaccess kuralları taşınmamış.
TLS sertifikası
Ücretsiz bir sertifika için olağan alan adı doğrulaması, HTTP üzerinden DNS'in şu anda gösterdiği adrese, yani hostinge yapılır. Bu yüzden geçişten önce üç yol var:
- Sertifikayı DNS üzerinden doğrulamayla almak:
certbot certonly --manual --preferred-challenges dns -d example.com -d www.example.com. certbot bir TXT kaydı eklemenizi isteyecektir. Böyle bir sertifika kendiliğinden yenilenmez, bu yüzden taşındıktan sonra olağan bir sertifika alın. - Panel dışa aktarmaya izin veriyorsa mevcut sertifikayı ve anahtarı hostingden geçici olarak taşımak.
- DNS'i değiştirip sertifikayı hemen
certbot --nginx -d example.com -d www.example.comkomutuyla almak. Birkaç dakika boyunca site HTTPS'te hata verecektir; küçük bir site için bu kabul edilebilir.
Sertifikayı aldıktan sonra otomatik yenilemeyi kontrol edin: certbot renew --dry-run.
Taşınma günü
- Siteyi yazmaya kapatın: bakım modunu açın veya en azından sipariş ve yorum kabulünü durdurun. Bir mağaza için bu birkaç dakikadır.
- Aynı rsync komutunu bir kez daha çalıştırın; yalnızca değişiklikleri aktaracaktır.
- Veritabanının güncel bir dökümünü alın ve VPS'te eskisinin üzerine yükleyin.
- Alan adının ve www'nin A kaydını sunucunun IP'siyle değiştirin. Alan adının hostingin IPv6 adresini gösteren bir AAAA kaydı varsa onu sunucunun IPv6 adresiyle değiştirin veya silin; aksi takdirde ziyaretçilerin bir kısmı eski sunucuya gitmeye devam eder.
- Yeni kayıtların göründüğünü kontrol edin:
dig +short example.com A @8.8.8.8vedig +short example.com AAAA @8.8.8.8. - Siteyi artık VPS'te yazmaya açın.
E-postayı kaybetmeyin
Taşınmanın en sık yaşanan sıkıntısı budur. MX kaydının nereyi gösterdiğine bakın: dig +short example.com MX. Orada example.com veya siteyle aynı IP'ye giden mail.example.com varsa A kaydının değiştirilmesi e-postayı posta sunucusu olmayan VPS'e gönderir. Geçişten önce e-posta için hostingin eski IP'sini gösteren ayrı bir kayıt oluşturup onu MX'te belirtin; daha da iyisi alan adının e-postasını önceden ayrı bir e-posta hizmetine taşıyın.
Site e-posta gönderiyorsa (siparişler, parola sıfırlama) taşındıktan sonra bunları kontrol edin. SPF kaydı olmayan yeni bir IP'den giden e-postalar spama düşer: ya sunucunun IP'sini SPF'ye ekleyin ya da e-postaları bir e-posta hizmetinin SMTP'si üzerinden gönderin. VPS'te kendi posta sunucunuz ayrı bir iştir; bunun için paketler posta sunucusu için VPS seçkisinde.
Taşındıktan sonra ve geri dönüş
Hostingi bir iki hafta kapatmayın. İlk saatlerde eski veritabanını kontrol edin: son döküm ile DNS değişikliği arasında biri eski sunucuda sipariş vermeyi başardıysa onu elle aktarın. Birkaç gün sonra hostingin erişim loguna göz atın: oraya hâlâ insanlar geliyorsa bir yerde eski adres kalmıştır, çoğunlukla AAAA veya www kaydında.
Hosting çalıştığı sürece geri dönüş basittir: DNS'te eski IP'yi geri yazın, kısa TTL sayesinde ziyaretçiler dakikalar içinde hostinge döner. Her şey oturduğunda TTL'yi olağan değerlerine döndürün, yedekleri VPS yedekleri: stratejiler ve araçlar yazısına göre ayarlayın ve harici izlemeyi kurun. Siteler için paketler: web sitesi için VPS, WordPress için VPS, e-ticaret sitesi için VPS, Bitrix için VPS. İlk deneme kurulumu için saatlik ücretlendirme kullanışlıdır.