Houve uma época em que a Dreamhost despontou como o Olimpo para blogs médios e grandes. Limites de transferência na casa dos TB, espaço em disco a perder de vista, domínios praticamente ilimitados… Na teoria, realmente, é o paraíso. Mas, tal qual a Tekpix nos ensina todos os dias, quando a oferta é muito boa, deve-se desconfiar. E quem migrou blogs de grande visitação para lá logo viu que, afinal, o paraíso não é tão agradável como pintam.

Com trocentos sites hospedados por máquina, os limites generosos da Dreamhost empacam em limitações físicas dos servidores. Se seu site sobrecarrega, recebe um Digg-effect, ou simplesmente tem visitação acima do irrisório, o servidor em que ele está hospedado pede água e você começa a incomodar os nanicos que estão na mesma máquina. E isso é só o começo da dor de cabeça…

(mt) Media Temple.

Recentemente, a (mt) Media Temple surgiu como uma alternativa “premium” à Dreamhost. O preço é um pouquinho mais elevado (começa em U$ 20,00/mês), mas em compensação os servidores aguentam o tranco melhor. Então, após ouvir muitas críticas positivas de amigos e contatos, assim que o WinAjuda saiu do iG, imediatamente assinei um plano com a (mt).

Backup feito, chegava a temida hora da restauração no novo servidor. Bati muito a cabeça, perdi dois dias e uma noite, mas, afinal, consegui. Ou melhor, conseguimos. Não fosse a imprescindível ajuda de vários amigos que se dispuseram a encarar esse desafio comigo, certamente ainda estaria com o site fora do ar e passando raiva. Agradecimento especial ao Vinícius Figueiredo, que matou a charada e permitiu a restauração perfeita do blog no novo servidor.

Para ajudar quem, porventura, migre para a (mt) algum dia, e de quebra contar a saga da migração, eis o post que você está lendo. Prontos para começar? Então vamos!

Backup

No servidor antigo, não tinha acesso aos bancos de dados pelo phpMyAdmin. Podia conectar-me a eles, mas através de um front end externo, como o MySQL-Front. A primeira tentativa de backup foi por ele. Frustrada. Não sei por qual motivo, mas os caracteres especiais (ã, é, ç) corrompiam durante o backup. Mostrou-se totalmente inútil.

Então, lembrei-me de um plugin muito útil para WordPress, o WP-BD-Backup. Com ele o backup ficou perfeito, com caracteres especiais mantidos, como deve ser. Então, fica a dica: tenha sempre esse plugin instalado e faça backups regulares do seu blog!

De resto, baixei temas, plugins e os arquivos da pasta /wp-content/uploads/. Há quem prefira baixar o WordPress inteiro do servidor antigo, mas não acho necessário. Nem mesmo plugins e temas o são. Baixei mesmo só por comodidade – tanto que reinstalei os plugins manualmente depois, e só restaurei um tema, o que está em uso.

Preparação

É preciso criar um banco de dados na hospedagem nova. Isso é bem simples na (mt), o painel é intuitivo e fácil, e se você está fazendo essa migração sozinho(a), certamente sabe como proceder. O usuário do BD é assimilado automaticamente aos bancos criados, então, não precisa preocupar-se com isso. Os dados de usuário, senha e host vêm na carta de ativação da hospedagem.

Se quiser, pode enviar os arquivos do WordPress para o servidor antes de proceder à restauração do banco de dados. Só bloqueie a instalação de alguma maneira, para evitar que algum engraçadinho fique brincando. Por exemplo, renomeie a pasta /wp-admin/, ou então o arquivo wp-config.php.

O banco de dados salvo pelo WP-BD-Backup vem compactador (*.tar.gz). É necessário descompactá-lo, algo que qualquer programa do gênero decente (7-Zip, WinRAR) faz sem maiores problemas. Feito isso, envie o arquivo *.sql para a pasta html do seu domínio, na (mt).

phpMyAdmin ou SSH?

A (mt) possui phpMyAdmin, mas ele é meio inútil para importação de bancos, afinal, só funciona com BDs que tenham menos de 10 MB. O do WinAjuda tem 40 MB, então… passei.

A outra maneira de restaurar bancos de dados é via SSH. Pode ser um bicho de sete cabeça para muita gente (eu incluso), mas é possível domá-lo, principalmente pela excelente documentação da hospedagem.

Antes de qualquer coisa, é preciso habilitar SSH na sua conta. Por questões de segurança, esse recurso vem desabilitado por padrão. No painel administrativo, clique em Server Administrator. Na próxima tela, marque a opção Enable para SSH options, e clique em Save. Pronto!

Para conectar via SSH, no caso do Windows, é preciso um programa de terceiro. O PuTTy é o que eu conheço, e funciona bem. Baixe-o, e prepare-se: a migração vai começar!

Restaurando um banco de dados através do PuTTy

A primeira conexão, provavelmente, falhará. Abra o PuTTy, e em Host Name, escreva o endereço do seu servidor na (mt). Ele provavelmente segue esse formato: sXXXXX.gridserver.com. Deixe a porta 22, do jeito que está, e marque a opção SSH. Tente conectar. Para tal, use seu domínio principal sem “www” como login, e a senha geral, a mesma dos outros serviços (FTP, MySQL, etc.). Não deu, né?

Normal. É preciso liberar seu IP no painel administrativo da hospedagem. Faça login novamente no painel, e ao entrar lá, um popup surgirá informando que houve uma tentativa de conexão via SSH. Do lado direito, há um botão escrito Unblock. Clique nele, aguarde 10 minutos e tente conectar novamente. Agora vai.

Usuários pós-Windows 95 sentirão calafrios ao ver essa tela:

PuTTy em ação.

Não é preciso ser fera, basta conhecer alguns comandos:

• ls: lista arquivos e diretórios (pastas);
• cd [nome do diretório]: acessa diretório especificado.

Para o que vamos fazer, isso é mais que suficiente. Navegue até a pasta html do seu domínio. Para encurtar a história, digite isso e dê Enter no final:

cd domains/dominio.com/html

Substitua “dominio.com” pelo seu domínio (Mr. Óbvio ataca novamente!). Dê um ls, e você verá a estrutura de arquivos e diretórios. Dentre eles, deve estar o banco de dados enviado antes de começarmos isso tudo. Está lá? Pois agora basta chamar o mysql para fazer o trabalho. E é aqui que está o pulo do gato.

A documentação da (mt) passa esse comando (NÃO O EXECUTE!):

mysql -u Username -p dbname < dbname.sql

Fiz e refiz ele mais de dez vezes, e em todas os caracteres corromperam. Mudei o charset do banco, mas nada de funcionar. Aí apareceu o Vinícius, e deu a dica: “obrigar” o importador a fazer o processo usando UTF-8. Bastou um adendo à sintaxe acima, e tudo funcionou maravilhosamente bem. Então, anotem essa sintaxe e guardem-na com suas vidas (ESTE É O COMANDO CERTO):

mysql -u Username -p --default_character_set utf8 dbname < dbname.sql

O comando --default_character_set utf8 (dois hífens no começo) força o banco de dados a usar UTF-8, e com isso, os acentos aparecem corretamente. O mais interessante é que essa dica funciona para qualquer banco de dados com caracteres especiais. Horas mais tarde, fiz o mesmo procedimento com o phpBB (sistema de fóruns), e funcionou de primeira. Senti um alívio tremendo quando abri o phpMyAdmin e vi um “Ícones do Office…” na tabela de posts do banco de dados .

A dica acima vale para o plano de hospedagem compartilhada, o (gs) Grid-Service. Nos demais planos, o procedimento, se não for igual, é parecido.

Espero que o tutorial seja útil a quem, algum dia, pretender migrar um banco de dados grande. Embora a dica seja baseada na (mt) Media Temple, ela funciona em qualquer hospedagem que ofereça acesso via SSH.