Atualizar GLPI ou outro sistema PHP sem medo: backup testado, depois o botão

O GLPI do suporte avisa que há uma versão nova com correções de segurança. Você atualiza numa terça às 10h, a migração do banco para no meio com um erro de plugin e o service desk de 40 técnicos fica sem abrir chamado. Tem backup? Tem, da semana passada, e ninguém sabe se ele abre. A resposta curta: atualização de sistema que muda o banco começa com um backup do banco e dos arquivos feito minutos antes, restaurado uma vez num canto para provar que funciona. Só então você atualiza, num horário combinado, com um roteiro de volta escrito. Se a migração falhar, você restaura; não "continua" em cima de um banco pela metade.

O exemplo é o GLPI da Construtora Horizonte, instalado em /var/www/glpi num servidor Debian com Apache e MariaDB, banco glpi. O roteiro vale, com outros nomes, para qualquer sistema PHP com banco: painel, loja, ERP pequeno.

Por que o "desfazer" não existe na atualização

A versão nova traz dois tipos de mudança. Os arquivos de código, que você pode trocar e destrocar à vontade, e as migrações do banco, que alteram tabelas, colunas e dados. Uma migração que renomeia uma coluna e converte valores não tem botão de desfazer. Se ela para na metade, o banco fica num estado que nem a versão antiga nem a nova esperam.

Além disso, há o que está ao redor: plugins que dependem de uma estrutura antiga, a versão mínima de PHP que subiu, extensões que a versão nova exige. Qualquer um deles pode quebrar a migração ou a tela depois dela. Por isso o backup não é burocracia: é a única forma de voltar ao estado de antes.

Antes de tocar em qualquer coisa

1. Leia as notas da versão e os requisitos: versão de PHP, extensões, versão do banco. Compare com php -v e php -m do servidor.
2. Anote os plugins ativos e as versões deles, e confirme se cada um tem versão compatível com a nova.
3. Combine a janela com quem usa o sistema e avise o horário. Atualização sem janela é atualização no meio do expediente.
4. Defina quanto dado você aceita perder. Se o backup é feito às 18h e a atualização às 18h30, chamados abertos nesse intervalo se perdem num rollback, a menos que o sistema esteja fora do ar.

Como fazer o backup que você vai precisar

Pare o acesso dos usuários (modo de manutenção do próprio sistema, se houver, ou o servidor web) e copie banco e arquivos com data no nome:

DATA=$(date +%F-%H%M)
mkdir -p /backup/glpi

mysqldump --single-transaction --routines --triggers glpi | gzip > /backup/glpi/glpi-$DATA.sql.gz

tar -czf /backup/glpi/glpi-arquivos-$DATA.tar.gz -C /var/www glpi

ls -lh /backup/glpi/

Em versões recentes do MariaDB, o comando também existe como mariadb-dump. O tar leva a pasta inteira, incluindo configuração, documentos anexados aos chamados e plugins. Se a sua instalação guarda configuração e dados fora da pasta do código (em /etc/glpi e /var/lib/glpi, por exemplo), inclua esses diretórios também. Para entender as opções do mysqldump em detalhe, veja backup de MySQL que restaura.

Prove que o backup abre

Um arquivo de dump que nunca foi restaurado é uma hipótese. Restaure num banco separado, no mesmo servidor ou numa máquina de teste:

mysql -e "CREATE DATABASE glpi_teste CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci"
gunzip -c /backup/glpi/glpi-$DATA.sql.gz | mysql glpi_teste
mysql -e "SELECT COUNT(*) FROM glpi_teste.glpi_tickets"
mysql -e "SELECT COUNT(*) FROM glpi.glpi_tickets"

Os dois números precisam ser iguais. Se o import falhar ou a contagem divergir, a atualização espera até você entender por quê. Depois do teste, apague o banco glpi_teste. O argumento completo está em o backup que ninguém restaurou.

A atualização em si

O procedimento exato muda de sistema para sistema e de versão para versão; siga a documentação oficial de atualização (para o GLPI, é a página da sourceUrl deste post). Em linhas gerais, para o GLPI:

1. Mova a pasta antiga para /var/www/glpi-antigo, sem apagar.
2. Extraia a versão nova em /var/www/glpi.
3. Traga de volta os diretórios de dados que a documentação indica (configuração, arquivos e plugins), a partir da pasta antiga.
4. Ajuste o dono dos arquivos para o usuário do servidor web, como www-data no Debian.
5. Rode a atualização do banco, pelo navegador ou pelo console. No GLPI 10, o console oferece php bin/console db:update; confira o nome exato do comando na documentação da sua versão.
6. Teste o essencial: login, abrir e fechar um chamado, anexar arquivo, os plugins que você anotou, as tarefas agendadas.
7. Libere o acesso e acompanhe o log de erros do PHP pela primeira hora.

Quando a migração falha: o caminho de volta

Escreva este roteiro antes de começar e deixe aberto num terminal:

DATA=2026-10-17-1830   # o carimbo do backup feito antes da atualização
systemctl stop apache2

mysql -e "DROP DATABASE glpi"
mysql -e "CREATE DATABASE glpi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci"
gunzip -c /backup/glpi/glpi-$DATA.sql.gz | mysql glpi

rm -rf /var/www/glpi
mv /var/www/glpi-antigo /var/www/glpi

systemctl start apache2

Antes de usar esse roteiro numa emergência, confirme que o charset e a collation do CREATE DATABASE são os mesmos do banco original, com SHOW CREATE DATABASE glpi. Melhor ainda: ensaie a volta no servidor de teste, como em rollback ensaiado. Com o sistema de volta, investigue o erro com calma, numa cópia, e só tente de novo quando entender a causa.

Erros comuns

• Atualizar com o backup de ontem. Tudo o que entrou hoje se perde se você precisar voltar.
• Nunca ter restaurado o dump. Você descobre no pior momento que o arquivo está truncado ou vazio.
• Copiar só o banco e esquecer os anexos e a configuração. O sistema volta, mas sem documentos dos chamados e sem conseguir conectar.
• Ignorar a versão de PHP exigida. A migração nem começa, ou a tela branca aparece depois dela.
• Esquecer os plugins. Um plugin incompatível quebra a migração ou uma tela específica que ninguém testou.
• "Continuar" depois de uma migração que falhou no meio. O banco fica num estado que nenhuma versão entende, e o conserto vira trabalho manual.

Checklist

• Notas da versão e requisitos foram lidos e comparados com o servidor.
• Plugins ativos estão anotados com versão compatível.
• A janela foi combinada e o acesso está bloqueado durante a atualização.
• Banco e arquivos foram copiados minutos antes, com data no nome.
• O dump foi restaurado num banco de teste e a contagem bateu.
• O roteiro de volta está escrito e foi ensaiado.
• Depois da atualização, login, chamado, anexo e plugins foram testados.

Se a atualização falhasse agora e você tivesse de voltar o backup mais recente, de quando ele é, e quanto tempo de dado você aceita perder?