Uma estratégia de backup de tenant para WordPress multi-tenant

Gerenciar uma frota de sites de clientes em uma única instalação do WordPress é eficiente até o dia em que alguém precisa de um restore. Se as suas ferramentas de backup operam apenas com a ideia de “todo o servidor”, o erro de um único cliente se transforma em tempo de inatividade para todos. Uma estratégia de backup multi-tenant precisa funcionar na granularidade de um tenant: fazer backup, limpar, enviar para o remoto (offload) e fazer o restore de cada cliente de forma independente. Este guia mostra como estruturar isso com o GrabWP Tenancy Pro.

Por que backups de frotas precisam de granularidade por tenant

A grande vantagem do multi-tenancy é que os tenants compartilham uma base de código, mas mantêm seus dados isolados. Sua estratégia de backup deve respeitar esse mesmo limite. Um snapshot de todo o servidor é ótimo para recuperação de desastres, mas é a ferramenta errada quando o Cliente A exclui uma página e a quer de volta. Fazer o restore de uma imagem completa do servidor para corrigir um tenant significa reverter também os pedidos, comentários e edições de todos os outros tenants.

O GrabWP Tenancy Pro trata cada tenant como sua própria unidade de backup. Um backup captura o banco de dados, os uploads, o conteúdo e a configuração daquele tenant; um restore reconstrói exatamente esses itens, e nada mais. Isso significa que você pode recuperar o Cliente A para o estado de ontem, enquanto o Cliente B continua recebendo inscrições na manhã de hoje. Para agências e provedores de hospedagem (hosts), essa é a diferença entre um conserto de cinco minutos e um incidente em toda a frota. Isso também mantém o raio de impacto reduzido: um restore ruim só poderá afetar o tenant específico que você selecionou.

Agendamento: padrões globais com substituições por tenant

Backups manuais não escalam quando se passa de um punhado de sites, então o agendamento é onde uma estratégia real começa. O GrabWP permite que você defina padrões globais para backups automáticos de tenant e, em seguida, os substitua por tenant. Cada tenant possui seu próprio estado de ativação, agendamento e contagem de retenção, para que o seu cliente principal possa executar backups com mais frequência do que um site institucional de baixo tráfego sem que você precise gerenciar dezenas de entradas de cron manualmente.

As opções de recorrência cobrem a variedade que a maioria das frotas precisa: a cada hora, duas vezes ao dia, diariamente, semanalmente, quinzenalmente e mensalmente. Escolha uma base global sensata e, em seguida, aumente a frequência dos tenants mais movimentados e diminua a dos mais tranquilos.

A retenção é a outra metade do agendamento. O GrabWP limpa os backups locais e remotos após uma execução bem-sucedida, mantendo apenas a contagem de retenção que você definiu. Isso mantém o uso do disco sob controle e evita que backups antigos se acumulem silenciosamente. Defina a retenção por tenant para que uma loja com muitas mudanças mantenha um histórico maior do que um site estático. Escolha números que se encaixem no seu próprio orçamento de armazenamento e expectativas de recuperação, em vez de copiar um padrão genérico.

Segurança externa com S3

Backups que ficam armazenados apenas no mesmo servidor que os sites que eles protegem não são verdadeiramente backups. O GrabWP suporta armazenamento remoto compatível com S3 para que os backups de cada tenant possam sair do servidor. O registro de driver permite que você reutilize as credenciais S3 que já configurou ou forneça credenciais S3 personalizadas para um bucket dedicado.

Alguns recursos tornam isso prático na escala de uma frota:

• Auto-offload inicia o upload para o S3 imediatamente após a conclusão de um backup, garantindo que não haja uma janela em que a única cópia seja local.
• Pull-to-local baixa um backup apenas remoto do S3 de volta para o servidor quando você precisa dele para um restore, para que você possa manter o servidor enxuto e ainda consiga se recuperar rapidamente.
• Remote deletion a partir da interface (UI) da lista de backup permite que você limpe uma cópia no S3 sem sair do dashboard.
• Limites de contagem de arquivos por tenant fazem a limpeza automática (auto-prune) de backups remotos antigos assim que um tenant excede o seu número configurado de arquivos no S3, para que o armazenamento remoto permaneça tão controlado quanto o armazenamento local.

A lista de tenants exibe um emblema de driver de armazenamento (S3 ou Local) para que você possa ver de relance quais tenants possuem proteção externa e quais não possuem. Use isso como um checklist: nenhum cliente deve ficar apenas no Local por muito tempo.

O fluxo de trabalho de restore

Um backup do qual você nunca fez um restore é uma esperança, não um plano. O restore do GrabWP é um processo estruturado em várias etapas com uma interface de progresso em AJAX, para que você possa observar a conclusão de cada etapa em vez de ficar olhando para um ícone de carregamento em branco. O backup em si roda como uma tarefa de 7 etapas; o restore roda como uma tarefa de 8 etapas, cobrindo o banco de dados, os uploads, o conteúdo e a configuração do tenant.

A página de restore oferece duas abas. A aba existing backups faz o restore de uma cópia que já está no disco, que é o caminho comum para “desfazer o que foi feito ontem”. A aba upload permite fazer o restore de um arquivo de backup que você traz para o servidor, que é como você move um tenant entre ambientes ou se recupera de uma cópia arquivada. O restore entre bancos de dados (cross-database restore) é suportado entre diferentes tipos de banco de dados, então um tenant capturado em um motor de banco de dados pode ser reconstruído em outro sem a necessidade de editar dumps manualmente.

A partir da UI de gerenciamento de backup, você pode listar, baixar, excluir e fazer o restore de backups anteriores armazenados em disco, para que todo o ciclo de vida permaneça em um só lugar. O hábito prático que vale a pena construir: periodicamente, faça o restore de um tenant em um ambiente de descarte e confirme se ele volta a funcionar limpo. É assim que você descobre se a sua estratégia funciona antes de precisar dela.

Observe o limite aqui. Trata-se do backup e restore por tenant dentro do GrabWP Tenancy Pro. O plugin gratuito separado GrabWP Restore é uma ferramenta diferente que reconstrói um arquivo ZIP exportado do Pro em um site independente (standalone). Recorra a ele quando estiver retirando um tenant da frota, e não para a recuperação de rotina da frota.

Automação com WP-CLI e Schedule Assurance

Tudo o que foi mencionado acima pode ser roteirizado via script. O GrabWP inclui comandos WP-CLI para executar um backup, configurar o agendamento de um tenant, exibir o status mais o histórico recente e reagendar todos os tenants de uma só vez. Isso faz com que os backups sejam uma parte de primeira classe dos seus fluxos de trabalho de provisionamento e CI: você inicia (spin up) um tenant, define seu agendamento e segue em frente. Reagendar toda a frota com um único comando é útil depois que você altera sua política global.

A ressalva com qualquer agendamento no WordPress é o WP-Cron, que só é disparado quando o site recebe tráfego. Em um tenant silencioso, um backup que “deveria” rodar diariamente pode acabar atrasando. O Schedule Assurance em Pro Settings existe exatamente para isso: ele mostra o status do WP-Cron, o próximo backup agendado, os intervalos disponíveis e, quando o WP-Cron está desativado, orientações para conectar um cron do sistema real. A configuração confiável para uma frota séria é desativar o WP-Cron e controlar o wp em um crontab do sistema, de modo que os backups agendados de tenant ocorram em um relógio fixo, independentemente do tráfego.

Uma estratégia de base recomendada

Juntando tudo, aqui está um ponto de partida sensato que você pode ajustar de acordo com as suas próprias necessidades de armazenamento e recuperação:

1. Defina um agendamento diário global como padrão, e então aumente os tenants movimentados (duas vezes ao dia ou por hora) e diminua os mais tranquilos (semanalmente).
2. Defina uma contagem de retenção por tenant que corresponda à taxa de mudança de cada tenant, para que lojas de alto tráfego mantenham um histórico mais profundo.
3. Ative o auto-offload para S3 para cada tenant e defina um limite de contagem de arquivos por tenant para que o armazenamento remoto se limpe sozinho (self-prunes).
4. Controle os agendamentos a partir do cron do sistema com o WP-Cron desativado, e verifique o Schedule Assurance após qualquer alteração.
5. Teste os restores regularmente reconstruindo um tenant em um ambiente de rascunho (scratch).

Isso lhe dá recuperação granular, armazenamento limitado em ambas as pontas e cópias externas (offsite) sem precisar ficar supervisionando.

O plugin base GrabWP Tenancy é gratuito no WordPress.org, e o backup por tenant, agendamento, envio para S3 (offload) e restore entre bancos de dados vêm com o GrabWP Tenancy Pro por $9.99/month. Se você ainda está decidindo como isolar os dados de tenant em primeiro lugar, leia nosso guia complementar sobre WordPress com MySQL dedicado vs SQLite por tenant.