Pipeline de Restore WordPress Multi-Tenant

O problema

Uma operação SaaS gerindo dezenas de sites WordPress tinha um plano de DR que funcionava no papel mas desmoronava na prática. Restores eram processo de várias horas, hands-on: alguém clicava por UIs de plugin, baixava arquivos de backup à mão, brigava com erros de permissão e cruzava os dedos para plugins incompatíveis não quebrarem o site silenciosamente.

Semanas depois, alguém notava que uma feature não funcionava — não porque o restore falhou, mas porque um plugin foi reativado em estado que ele não sabia tratar. A confiança no pipeline de backup estava ruindo rápido.

A abordagem

Tornar o restore mecânico e verificável.

Extensão AIO WP Migration v3.96+ como ferramenta canônica de import, chamada via WP-CLI em modo não-interativo. A UI ficou off-limits — cada passo tinha que ser reproduzível por CLI.

S3 como ground truth dos backups — backups vão pra lá, restore lê de lá. Sem desvio "baixar pro laptop, subir pro servidor".

Passo determinístico de correção de permissões: reset de ownership e modes em todo restore, sem depender do que o último admin fez à mão.

Allowlist de compatibilidade de plugins: lista conhecida de plugins que precisam de reativação pós-restore em ordem específica. Plugins fora da lista são desativados e expostos para revisão manual em vez de quebrar silencioso.

Passo de auto-verificação: check sintético em 5 URLs canônicas após restore valida o formato da resposta antes de declarar o restore verde.

Orquestração Bash com logs estruturados — cada passo tem checkpoint e o pipeline retoma de um restore parcial.

A maior parte da engenharia aconteceu na camada chata: definir o que "restaurado" realmente significa e recusar declarar pronto até essa definição estar atendida.

O resultado

Tempo de restore caiu de 6-8 horas de trabalho humano focado para menos de uma hora de pipeline majoritariamente não-supervisionado. Reprodutibilidade chegou a 100% — o mesmo backup gera o mesmo site toda vez. Restores silenciosos acabaram: todo restore ou passa na verificação ou falha alto.

O time parou de tratar DR como tarefa temida e passou a tratar como operação rotineira.

Por que isso importa

Pipelines de DR que parecem bem em tabletop exercise frequentemente desmoronam no dia real do recovery. Os ganhos vêm de remover cada passo onde um humano cansado no meio de incidente tem que fazer julgamento. Automatize as decisões chatas, deixe as genuinamente interessantes ("restauramos de ontem ou da semana passada?") para pessoas.