Blog

Não me lembro bem ao certo o momento em que iniciei meu blog rra.etc.br, mas ele foi criado como uma válvula de escape às mazelas da vida. Um lugar onde eu podia dedicar alguns momentos de minha vida a uma área pela qual sempre tive grande paixão: a informática.

Este blog reunia diversas experiências pessoais com o Linux, desde a instalação até a configuração de serviços, kernel, programação em bash script, Python, PyQt e tudo mais que me vinha à cabeça. Eu essencialmente imergia em tudo que pudesse fazer em meus computadores e notebooks na ocasião, relacionado ao Linux e, especialmente, ao Slackware, minha distribuição preferida por boa parte dessa época.

Iniciei com o Linux Slackware no final de 1994, instalado pelo meu amigo Manuel Andrade, em um recém-adquirido 486DX266. Desde então, mantive-o em minha máquina pelo simples fato de me permitir escrever códigos em Fortran e trabalhos em Latex, que eram parte de minha rotina na época de Mestrado em Física na UNICAMP.

Desde então, sempre gostei de “mexer” no meu sistema e tentar compreendê-lo. Essa interação com o Slackware/Linux me era suficiente e foi assim até por volta de 2002, quando assumi uma cadeira de Física para Ciência da Computação no Centro Universitário de Vila Velha, hoje Universidade de Vila Velha (UVV), no ES. Neste momento, aproveitei a oportunidade para fazer algumas orientações informais aos alunos sobre o mundo Linux. Em algum momento entre este ano e os seguintes, achei conveniente criar o blog (rra.etc.br) para organizar minhas investigações no sistema e me aprofundar mais em alguns tópicos. Era uma época em que quase tudo que se necessitava saber do mundo Linux estava à mão nos HowTos disponibilizados na documentação do sistema operacional no Slackware.

Mantive este site ativo até por volta de maio de 2019, quando, motivado por diversos acontecimentos que me acometeram nos últimos 18 meses, me convenci de que era o momento de fechar o site. Um dos fatores decisivos para o fechamento do blog foi a abertura da loja física de uma loja on-line de BoardGames que minha esposa vinha gerenciando há quase um ano, um dos motivos pelo qual tinha pouco tempo disponível para o blog, visto que dedicava muitas horas apoiando esta iniciativa, construindo e gerenciando a loja virtual em Woocommerce, uma plataforma open-source para WordPress.

Na ocasião, não dispunha de muito tempo livre para manter o rra.etc.br ativo, e toda a minha experiência e criatividade estavam focadas em escrever artigos e desenvolver conteúdo para a loja virtual e seus BoardGames, além de minhas aulas na UVV, que me colocavam em cadeiras mais técnicas das engenharias, preparando novas disciplinas para além do básico das Físicas.

Após esta longa introdução histórica, vamos ao interesse deste artigo. Neste artigo pretendo restaurar o conteúdo deste blog em uma máquina local, através do XAMPP. Este texto será um relato desse processo, para que possa manter o conteúdo acessível e disponível para todos os interessados.

XAMPP + Php + MariaDB

Nas palavras do projeto, o “XAMPP é uma distribuição do servidor Apache fácil de instalar, contendo MariaDB, PHP e Perl“.

Além de reunir as ferramentas básicas para minha tarefa, o XAMPP possui outra característica muito relevante para a recuperação de uma página desativada: a diversidade de combinações Apache+Php+MariaDB disponíveis nos repositórios, como pode ser visto em Sourceforge.net: Xampp Files Linux.

Até onde testei, a numeração parece referir-se à versão do Php, e as datas dos pacotes variam de 27 de agosto de 2003 até a data atual. Não posso afirmar se todas as versões do pacote XAMPP disponíveis correspondem às versões do Php, mas a data do empacotamento já é uma boa referência para uma escolha mais assertiva do pacote adequado à restauração.

Para este texto, vou usar o pacote 7.0.33 de 13/12/2018. Lembro-me de não fazer muitas atualizações ao Php neste servidor e é bem provável que a versão da época seja ainda mais inferior a 7.0.33, embora me lembre de ter atualizado para uma versão 7 em algum momento.

Instalação do XAMPP

Após baixar a versão do XAMPP para uma pasta local, basta alterar a permissão para executável e rodar o arquivo com sudo:

rudson@suzail:~$ chmod +x ~/Downloads/xampp-linux-x64-7.0.33-0-installer.run
rudson@suzail:~$ sudo ~/Downloads/xampp-linux-x64-7.0.33-0-installer.run
[sudo] password for rudson:

Isso abrirá o diálogo de instalação. Neste ponto, basta clicar em Next até concluir a instalação.

Como pode ser visto no slide acima, o XAMPP é instalado na pasta /opt/lampp. Ao finalizar, o XAMPP se abrirá em uma janela semelhante à imagem a seguir:

As três abas do XAMPP estão abertas acima, mas o foco neste momento é a segunda, onde se pode iniciar, parar, reiniciar e editar o arquivo de configuração do servidor Apache (/opt/lampp/etc/httpd.conf).

Contudo, neste momento, o servidor já está operacional e pode ser testado acessando http://localhost em um navegador de sua preferência.

Criando uma entrada para o Menu

Para finalizar a instalação, é conveniente criar uma entrada no menu do seu sistema para o XAMPP. Para isso, crie um arquivo “xampp.desktop” na pasta ~/.local/share/applications/ com um editor de sua escolha e adicione o seguinte conteúdo:

[Desktop Entry]
Encoding=UTF-8
Name=XAMPP Control Panel
Comment=Start and Stop XAMPP
Exec=sudo /opt/lampp/manager-linux-x64.run
Icon=/opt/lampp/htdocs/favicon.ico
Categories=Development
Type=Application
Terminal=true

O comando cat a seguir cria o arquivo “xampp.desktop” no local correto:

rudson@suzail:~$ cat << EOF > ~/.local/share/applications/xampp.desktop
[Desktop Entry]
Encoding=UTF-8
Name=XAMPP Control Panel
Comment=Start and Stop XAMPP
Exec=sudo /opt/lampp/manager-linux-x64.run
Icon=/opt/lampp/htdocs/favicon.ico
Categories=Development
Type=Application
Terminal=true
EOF
rudson@suzail:~$ 

Isso deve adicionar uma entrada para o XAMPP no menu Development ou no menu geral, dependendo da interface gráfica que estiver usando.

Configurações do XAMPP

Neste ponto, o diretório padrão de documentos do servidor está definido para “/opt/lampp/htdocs/“. Para este projeto, recomendo fazer algumas personalizações no servidor, incluindo a mudança deste diretório. Os arquivos do servidor, no meu caso, serão alocados na pasta ~/Public/www.

Para editar as configurações, você pode acessar o arquivo “httpd.conf” diretamente através do XAMPP (Configure -> Open Conf File -> Yes) ou invocar um editor de sua escolha pelo terminal com um comando sudo:

rudson@suzail:~$ sudo vim /opt/lampp/etc/httpd.conf
…

As alterações necessárias no arquivo “/opt/lampp/etc/httpd.conf” são mostradas abaixo:

…
<IfModule unixd_module>
  User rudson
  Group rudson
</IfModule>
…
DocumentRoot "/home/rudson/Public/www"
<Directory "/home/rudson/Public/www">
    Options Indexes FollowSymLinks ExecCGI Includes
    AllowOverride All
    Require all granted
</Directory>
…

O próximo passo é criar algum conteúdo na pasta /home/rudson/Public/www para testar o servidor. O comando a seguir cria o arquivo index.php exibindo as informações do phpinfo():

rudson@suzail:~$ mkdir -p /home/rudson/Public/www
rudson@suzail:~$ cat << EOF > /home/rudson/Public/www/index.php
<?php
phpinfo();
?>
EOF

Embora não seja estritamente necessário, é conveniente habilitar o PHP distribuído pelo XAMPP, criando um link simbólico do PHP do XAMPP para o sistema:

rudson@suzail:~$ sudo ln -s /opt/lampp/bin/php /usr/bin/
[sudo] password for rudson:
rudson@suzail:~$ php -v
PHP 7.1.25 (cli) (built: Dec 8 2018 11:46:12) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies

Após esses ajustes, podemos reiniciar o Apache (pressionando o botão Restart no XAMPP) e acessar novamente a página http://localhost para testar as alterações. Isso deve exibir uma página semelhante à seguinte no navegador:

Restaurar o Banco de Dados e o WordPress do Site

O próximo passo é restaurar o banco de dados e os arquivos do backup. Este site, em questão, estava hospedado no SiteGround e tomei o cuidado de fazer um backup do banco de dados e também dos arquivos do blog no momento de fechar o domínio.

Primeiro inicie o MySQL Database no XAMPP:

• Selecione a aba Manage Servers;
• Selecione o servidor MySQL Database;
• e pressione Start.

Assim que o servidor MySQL estiver ativo, poderemos proceder com a recuperação do banco de dados.

O banco de dados está no arquivo “u589704855_blog.20190508013342.tar.gz“, onde o “u589704855” se refere ao usuário na conta da SiteGround e o “20190508013342” se refere a data e hora do backup.

Descompacte o arquivo do banco de dados em um diretório apropriado:

rudson@suzail:~$ tar xvf u589704855_blog.20190508013342.tar.gz
u589704855_blog.sql

Em seguida, abra o phpMyAdmin para importar o banco de dados.

phpMyAdmin

O phpMyAdmin é uma ferramenta de software livre escrita em PHP, destinada a administrar banco de dados MySQL, já incluso no pacote do XAMPP. Acesse-o no endereço http://localhost/phpmyadmin.

Para carregar o banco de dados, clique em New na árvore à esquerda. Isto irá abrir a página para a criação de um novo banco de dados.

Dê um nome ao banco de dados, no caso vou usar “rraetcbr_db“, e pressione no botão Criar ao lado.

Para importar o conteúdo do banco de dados u589704855_blog.sql para o rraetcbr_db, clique na aba Importar:

Primeiro pressione o botão Procurar e busque o arquivo do banco de dados no sistema, no meu caso o arquivo “u589704855_blog.sql“. Para iniciar a importação pressione o botão Executar, na base da página. Isto deve levar alguns instantes para carregar todos os ficheiros do banco de dados. Ao terminar deve aparecer uma página semelhante a abaixo:

Um aspecto importante a ser observado na lateral esquerda da página do phpMyAdmin são os prefixos dos nomes das tabelas do banco de dados: “wpstg0_” e “wp_“. As tabelas com o prefixo “wpstg0_” são tabelas de staging, criadas por um plugin específico para essa finalidade. Lembro-me de ter utilizado esse processo em algum momento de 2018, durante a migração dos meus sites da Hostinger para a SiteGround, impulsionado pela crescente demanda no servidor devido à loja virtual de Boardgames.

Para verificar qual prefixo estava em uso no blog no momento do backup, é suficiente consultar o arquivo wp-config.php do WordPress. A informação necessária encontra-se na declaração da variável $table_prefix:

…
/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix  = 'wp_';

/**
 * WordPress Localized Language, defaults to English.
…

Neste momento, ainda não realizei a instalação dos arquivos do blog, mas planejo fazê-lo em breve.

Ao redirecionar a atenção para o phpMyAdmin, apliquei um filtro “wp_” para exibir apenas as tabelas utilizadas pelo blog. Observe que o WordPress gera uma ampla variedade de tabelas no banco de dados. Algumas são criadas pelo próprio WordPress, enquanto outras resultam da instalação de plugins.

Uma das tabelas mais fundamentais no WordPress é a “wp_options“. Ela armazena uma variedade de dados vitais para o funcionamento do site, incluindo configurações gerais, configurações de temas, de plugins e informações temporariamente armazenadas em cache. Entre os campos chave estão:

• siteurl e home: armazenam as URLs do seu site WordPress.
• admin_email: o e-mail do administrador do site.
• blogname e blogdescription: o nome e a descrição do seu blog.
• Configurações relacionadas a mídia, como thumbnail_size_w, thumbnail_size_h, medium_size_w, medium_size_h, entre outros, que determinam os tamanhos padrão das imagens.

Atualmente, o foco será em campos específicos como siteurl e home, que estão configurados para o antigo domínio “http://rra.etc.br/Myworks”. A pasta “Myworks” será mantida inalterada, já que pretendo importar os arquivos de conteúdo exatamente como estavam no servidor da SiteGround. Contudo, o domínio deve será alterado para “http://localhost“.

Mas antes de sair fazendo alterações façamos mais algumas buscas pela ocorrência do domínio “http://rra.etc.br” na tabela wp_options. Com o banco de dados selecionada pressione a aba Pesquisar e preencha:

• o campo option_value com a url http://rra.etc.br;
• escolha a opção “LIKE %…%” para que a pesquisa encontre ocorrências da URL em qualquer parte do valor da coluna.

Por fim pressione Executar. No meu caso, a pesquisa no banco de dados retornou 19 ocorrências.

Todas essas ocorrências precisam ser atualizadas para o domínio “http://localhost” para garantir o funcionamento correto do site.

No entanto, antes de proceder com as substituições manuais, é prudente realizar uma análise mais aprofundada. Uma pesquisa abrangente no banco de dados pode ser feita seguindo os passos abaixo:

• com o banco de dados rraetcbr_db selecionado, na lateral esquerda;
• clicar na aba “Pesquisar“;
• no campo “Palavra(s) ou valor(es) a pesquisar (wildcard: “%”):” adicionar a url http://localhost;
• na lista de tabelas “Dentro de Tabela(s):” vou selecionar apenas as tabelas com prefixo “wp_“;
• por fim pressione o botão “Executar“.

No meu caso, a busca resultou na extensa lista de ocorrências encontradas em diversas as tabelas, que resumo a seguir:

O processo revelou um total de 490 ocorrências, tornando a edição manual inviável. A maioria dessas ocorrências consiste em links para imagens na base de arquivos – que ainda preciso transferir para o servidor –, links para outros posts no blog, e links relacionados a plugins, entre outros aspectos menos críticos para o funcionamento do blog.

No entanto, é importante destacar outro aspecto. Na hospedagem da SiteGround, os arquivos do blog estavam localizados no diretório “/home/u589704855/public_html“. Na minha configuração atual, eles estão no “/home/rudson/Public/www“. Uma busca no banco de dados por referências a “/home/u589704855/public_html” revelou mais uma ocorrência na tabela wp_options, especificamente na coluna recently_edited. Esta alteração, aparentemente, não é de grande importância.

Quanto a execução destas alterações necessárias no banco de dados, há diversas abordagens disponíveis:

1. Utilização de um Plugin: Caso o site esteja operacional no WordPress, é possível utilizar um plugin como o “Better Search Replace“. Este plugin facilita a realização de buscas e substituições em massa no banco de dados e oferece a vantagem de um “dry run“, que permite visualizar as alterações antes de aplicá-las permanentemente.
2. Comandos SQL via phpMyAdmin: Para quem possui familiaridade com SQL, é possível realizar substituições utilizando comandos de atualização (UPDATE) diretamente no phpMyAdmin. Esta abordagem exige conhecimento técnico mais aprofundado e deve ser executada com cuidado para evitar erros.
3. Script PHP de Substituição: Outra opção é utilizar um script PHP como o “Search Replace DB” da Interconnect/IT. Esta ferramenta oferece uma maneira eficaz de buscar e substituir dados em um banco de dados WordPress, contando com uma interface de usuário amigável para facilitar o processo.

Considerando que as referências atuais no banco de dados apontam para o domínio http://rra.etc.br, tornando o blog inoperante, a utilização de um plugin no WordPress não é viável no momento.

Comando SQL via phpMyAdmin

Para substituir as ocorrências de “http://rra.etc.br” por “http://localhost“, você pode executar um comando SQL no phpMyAdmin. O comando de atualização (UPDATE) será aplicado em todas as tabelas relevantes:

UPDATE wp_commentmeta SET meta_value = REPLACE(meta_value, 'http://rra.etc.br', 'http://localhost') WHERE meta_value LIKE '%http://rra.etc.br%';
UPDATE wp_comments SET comment_content = REPLACE(comment_content, 'http://rra.etc.br', 'http://localhost') WHERE comment_content LIKE '%http://rra.etc.br%';
UPDATE wp_golfresult SET column_name = REPLACE(column_name, 'http://rra.etc.br', 'http://localhost') WHERE column_name LIKE '%http://rra.etc.br%';
…

É crucial verificar e aplicar o comando nas colunas apropriadas de cada tabela.

No entanto, uma alternativa mais simples é utilizar o script PHP “Search Replace DB“. Este script facilita o processo de substituição em todo o banco de dados, minimizando o risco de erros manuais e agilizando o processo.

Script Search Replace DB

Este script é uma ferramenta útil projetada para auxiliar na migração de sites baseados em PHP e MySQL, sendo particularmente eficaz com o WordPress.

Para utilizá-lo, acesse o diretório onde os arquivos do servidor estão localizados, no caso ~/Public/www/, e clone o repositório do projeto do GitHub Search Replace DB:

rudson@suzail:…/www/$ git clone https://github.com/interconnectit/Search-Replace-DB
Cloning into ‘Search-Replace-DB’…
remote: Enumerating objects: 1174, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 1174 (delta 7), reused 10 (delta 5), pack-reused 1155
Receiving objects: 100% (1174/1174), 1.31 MiB | 5.77 MiB/s, done.
Resolving deltas: 100% (633/633), done.
rudson@suzail:…/www/$ ls
index.php Search-Replace-DB

Para utilizar o Search Replace DB, insira a url http://localhost/Search-Replace-DB/ no seu navegador. Isso abrirá a seguinte página:

Para realizar a substituição, preencha o formulário com as seguintes informações:

Search Replace:

• replace: http://rra.etc.br
• with: http://localhost

Database Details:

• database name: rraetcbr_db
• username: root
• pass: — em branco —
• host: localhost
• port: — em branco —

Por padrão, o usuário root não tem senha configurada. A porta padrão do MySQL é 3306, mas pode ser deixada em branco, pois o Search Replace DB identificará automaticamente o servidor.

Clique em “Test connection” para verificar a conexão. Se houver erros, uma mensagem será exibida nesta parte da página.

Which Tables?

• select tables: selecionei todas as tabelas com prefixo “wp_“, do banco de dados.

Com a conexão do banco de dados estabelecida, as tabelas serão listadas ao escolher a opção select tables.

Mais abaixo, na seção “Let’s go“, há um botão “Do a safe test run”. Ao clicá-lo, você pode executar um teste de verificação sem realizar alterações permanentes. Isso gerará uma lista de todas as tabelas e as mudanças propostas para o banco de dados.

O Search Replace DB identificou um número significativamente maior de alterações do que a busca realizada no phpMyAdmin, totalizando 625 mudanças específicas.

Se estiver satisfeito com os resultados identificados, simplesmente pressione o botão “Search and Replace” para aplicar efetivamente as alterações no banco de dados.

Após concluir este processo, recomendo acessar novamente a tabela wp_options para verificar, principalmente, os registros site_url e home, garantindo que as modificações foram implementadas corretamente.

Restaurar o Conteúdo do Site

O conteúdo do site, que foi compactado e salvo no arquivo “u589704855.20190508013342.tar.gz” no SiteGround ao encerrar o site, será agora descompactado. O processo de descompressão será realizado na pasta ~/Public/www/:

rudson@suzail:…/www/$ cd ~/Public/www
rudson@suzail:…/www/$ tar xvf ~/Downloads/Backups/u589704855.20190508013342.tar.gz
u589704855/
u589704855/DO_NOT_UPLOAD_HERE
u589704855/.logs/
u589704855/.logs/php_mail.log
u589704855/.logs/php_mail.log-20141204
u589704855/.logs/php_mail.log-20161121.gz
…
u589704855/public_html/
u589704855/public_html/default.php
u589704855/public_html/linux/
u589704855/public_html/linux/zdt/
u589704855/public_html/linux/zdt/zdt-1.0.0-x86_64-4rra.txz
u589704855/public_html/linux/bumblebee/
…
u589704855/public_html/MyWorks/
u589704855/public_html/MyWorks/wp-config.php
u589704855/public_html/MyWorks/php-errors.log
…
rudson@suzail:…/www/$ mv u589704855/public_html/* .
rudson@suzail:…/www/$ rm -rf u589704855 index.php
rudson@suzail:…/www/$ ls
default.php  images   MyWorks   pessoal   Search-Replace-DB
fisica       linux    others    python    u589704855_blog.sql

Este backup contém, além do site principal, outros domínios e diversas pastas com arquivos para download, imagens, PDFs, entre outros. Após descompactar, transferi todo o conteúdo da pasta “u589704855/public_html” para ~/Public/www/ e removi arquivos epastas que não tenho interesse no momento.

Reconfigurar o WordPress

O site WordPress que desejo recuperar está localizado na pasta MyWorks. O primeiro passo é ajustar o arquivo de configuração do WordPress, MyWorks/wp-config.php, para adaptá-lo à nova instalação:

…

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('WP_CACHE', true); //Added by WP-Cache Manager
define('DB_NAME', 'rraetcbr_db');

/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', '');

/** MySQL hostname */
define('DB_HOST', 'localhost');
…
$table_prefix  = 'wp_';
…
define('WP_DEBUG', true);
…
ini_set('error_log', '/home/rudson/Public/www/MyWorks/php-errors.log');
…

Aqui, destaco apenas os aspectos mais relevantes. É essencial configurar corretamente:

• DB_NAME: o nome no banco de dados;
• DB_USER: o nome do usuário do banco de dados;
• DB_PASSWORD: a senha do usuário;
• DB_HOST: o servidor MySQL.

O valor de $table_prefix é apresentado para verificação, mas não foi alterado. Ativei o modo de depuração (WP_DEBUG) para monitorar possíveis problemas e redirecionei o error_log para o arquivo de log apropriado.

Quanto aos arquivos de log (arquivos *.log), embora possam ser removidos, optei por mantê-los como um registro de bugs antigos. Se surgirem problemas, é útil verificar se estes não são remanescentes de antes da recuperação.

Por fim, é importante realizar algumas alterações nos arquivos locais, substituindo todas as ocorrências de rra.etc.br por localhost e /home/u589704855/public_html/ por /home/rudson/Public/www/, refletindo as configurações da nova instalação.

Essas substituições podem ser realizadas diretamente no terminal utilizando os seguintes comandos:

rudson@suzail:…/www/$ grep -lr ‘rra.etc.br’ MyWorks/* | xargs sed -i ‘s|rra.etc.br|localhost|g’
rudson@suzail:…/www/$ grep -lr ‘/home/u589704855/public_html’ MyWorks/* | xargs sed -i ‘s|/home/u589704855/public_html/|/home/rudson/Public/www/|g’

É importante notar que a maioria dos arquivos afetados por estas substituições foram arquivos de log. Como mencionei anteriormente, decidi mantê-los para referência futura.

Após concluir estas etapas, chegou o momento de acessar a página e verificar o resultado:

A recuperação do blog não foi 100% completa, mas o caminho é este. Alguns plugins apresentaram problemas devido a código legado, exigindo correções da minha parte. Outros, menos importantes, optei por simplesmente desativar.

Restaurar a Senha do Admin

Encontrei um problema com a senha do administrador, que acho importante adicionar aqui. Para solucioná-lo, recorri novamente ao phpMyAdmin. Primeiro, acessei a tabela wp_users:

Clicando em “Editar” na linha correspondente ao usuário “admin“, fui direcionado para a página de edição:

Na coluna user_pass, insira uma nova senha e selecione a função MD5 para criptografá-la. Após isso, clique em “Executar” para concluir a alteração da senha.

Com a senha restaurada, basta acessar a tela de login do WordPress, entrar no setup do WordPress e realizar as atualizações necessárias no sistema.

Conclusão

Ao longo deste artigo, compartilhei os passos que segui para restaurar uma instalação antiga de meu blog WordPress. O processo abrangeu desde a recuperação do banco de dados e do conteúdo do site até a reconfiguração do WordPress e a restauração da minha senha de administrador. Essa experiência demonstrou que é possível reviver um site WordPress antigo, mesmo quando se enfrentam desafios como a perda de informações cruciais.

Após a restauração, dediquei-me aos upgrades necessários. Atualizei o WordPress, os plugins e até o próprio XAMPP. Essas atualizações são essenciais para assegurar a segurança e o funcionamento eficiente do site, especialmente em um campo tecnológico que evolui rapidamente.

Espero que meu relato sirva como um guia prático e encorajador para aqueles que enfrentam a tarefa de recuperar sites WordPress antigos. Que as informações e dicas aqui apresentadas sejam valiosas e facilitadoras nesse processo, que, apesar de parecer desafiador, é completamente realizável com as instruções adequadas.