Hospedagem de backups e restauração: construir um plano de recuperação
Planejar hospedagem de backups em torno de arquivos, bancos de dados e perda de dados aceitável. Compreenda pontos de restauração semanal ou diária e teste de recuperação longe de seu site ao vivo.
Escolha quanto trabalho recente você pode se dar ao luxo de perder
Comece com os dados que mudam: conteúdo do site, uploads, registros de banco de dados, armazenar pedidos e configuração de aplicativos. Decida quanto trabalho recente você poderia reconstruir depois de um fracasso. Um portfólio raramente editado e uma loja recebendo ordens ao longo do dia pode precisar de diferentes planos de recuperação.
Compare essa necessidade com o cronograma de backup que você escolher. Se ocorrerem mudanças importantes entre as cópias agendadas, decida como as preservará. Uma programação diária não significa que cada transação é continuamente recuperável, e uma opção de backup não é uma garantia de um determinado tempo de recuperação.
Distinguir frequência de backup da retenção de ponto de restauração
O configurador VPSLibre não oferece backups adicionais, backups semanais ou backups diários. A opção semanal descreve um backup por semana com sete pontos de restauração; a opção diária descreve um por dia com sete pontos de restauração. Estas são opções de serviço solicitadas, com suas próprias linhas de cotação quando selecionadas.
Sete pontos de restauração são sete cópias retidas, não uma promessa universal de sete dias. Suas datas e cobertura utilizável dependem da programação escolhida e cópias completas bem sucedidas. Após a entrega, verifique as informações de backup reais, os dados cobertos, onde as cópias são mantidas e como a recuperação é solicitada antes de confiar no serviço.
Sem uma opção de backup adicional, você gerencia seu próprio plano de backup. Armazenamento de serviço adicional é uma opção separada e não cria backups. Mantenha uma cópia independente de dados importantes para que sua recuperação não depende de uma conta ou um ambiente.
Faça cada conjunto de recuperação completo e identificável
A recuperação WordPress normalmente precisa tanto de arquivos e do banco de dados. Envios, temas, plugins e configuração ao vivo em arquivos, enquanto posts, configurações e outros dados da aplicação também vivem no banco de dados. O download do diretório do site sozinho normalmente não captura seu banco de dados.
Para qualquer aplicação, listar os dados e configuração necessários para recriar um ambiente de trabalho. Agrupar arquivos compatíveis e exportar banco de dados no momento em que eles representam. Grave a versão da aplicação e os requisitos ambientais relevantes, e proteja cópias que contenham credenciais ou dados pessoais.
Verifique o escopo de um backup de serviço em vez de assumir que inclui todas as dependências externas. Os dados detidos por um serviço de terceiros precisam dos seus próprios mecanismos de recuperação. Uma cópia sincronizada que reproduz imediatamente as deleções também pode ser insuficiente quando você precisa de uma versão mais antiga.
Preparar um ambiente separado com os requisitos necessários para o conjunto de recuperação escolhido. Restaure as cópias usando as ferramentas apropriadas para sua aplicação e o acesso realmente disponível. Use credenciais separadas e restrinja o acesso a dados pessoais ou de clientes restaurados.
Evite que o ambiente de teste envie e-mails reais, carregue clientes ou execute integrações ao vivo. Verifique páginas representativas, mídia, logins e registros de banco de dados. Para uma loja, verifique se os dados da ordem recuperada correspondem ao ponto esperado no tempo sem iniciar transações reais do cliente.
Gravar o que funcionou, o que estava faltando e quanto tempo o seu próprio teste levou. Essa observação ajuda a melhorar o seu plano de recuperação; não é uma garantia de tempo de restauração publicada. Mantenha o ambiente vivo intacto enquanto resolve falhas de teste.
Restaurar WooCommerce sem descartar novas ordens
Restaurar um banco de dados de loja mais antigo pode remover pedidos, clientes ou alterações de estoque criados após esse backup. Gravar o ponto de recuperação e identificar o que mudou desde que ele antes de substituir dados vivos. Os registros de pagamento-fornecedor são separados da base de dados do site; uma tela de ordem restaurada não estabelece que esses dois registros concordam.
Ensaiar a restauração em uma cópia isolada com integrações de saída contidas. Concordo em como as transações recentes serão reconciliadas e quem pode autorizar a reabertura do checkout. Para um problema de código ou extensão, primeiro estabeleça se um rollback direcionado pode resolvê-lo sem substituir todo o banco de dados da loja. Um produto CSV não é uma cópia completa de pedidos, clientes ou registros de assinatura.
Grave o tempo de backup e a última referência de ordem ao vivo.
Identificar pedidos, clientes e alterações de ações após esse ponto.
Reconcile os registros de pagamento e cumprimento antes de reabrir o checkout.
Verifique o aplicativo restaurado e mantenha o registro de reconciliação.
Faça backup dos volumes Docker Compose como dados de aplicação
Mantenha a configuração Compose e um inventário de volumes nomeados, vincular montagens, exportações de banco de dados e uploads. Recrear recipientes de suas imagens restaura o código, não os registros mantidos nesses caminhos de dados. Use o procedimento de backup suportado pelo banco de dados ou aplicativo para obter um conjunto consistente; copiar um volume vivo sem esse procedimento não é um backup de banco de dados verificado.
Restaurar em um projeto isolado com nomes de volume e destinos separados. Recriar os serviços aprovados, verificar a propriedade e a configuração, em seguida, test representative lê e escreve contra os dados restaurados. Grave a versão e o tempo de instantâneo usados. Evite apontar o ensaio para dados de produção ou integrações ao verificar a recuperação.
Manter o plano de recuperação utilizável à medida que o projeto muda
Reveja o plano quando você adicionar um banco de dados, mover arquivos, alterar software ou introduzir uma nova integração. Faça uma cópia recuperável antes de uma grande mudança de aplicativo e verifique se as instruções de recuperação ainda correspondem ao ambiente. Utilizar as informações reais de gestão de serviços para qualquer procedimento específico do prestador.
Antes de substituir os dados ao vivo, decida quais novas mudanças devem ser preservadas e quem pode aprovar a operação. Para uma loja movimentada, uma base de dados mais antiga completa pode omitir pedidos mais recentes. Identificar o ponto de recuperação necessário e um caminho de retrocesso antes que um administrador realize a restauração ao vivo.
Grave os dados para proteger e a janela de perda aceitável.
Confirme o cronograma selecionado, pontos de restauração retidos e escopo de backup real.
Mantenha arquivos completos, banco de dados e conjuntos de configuração com datas identificáveis.
Armazene uma cópia protegida independente e verifique quem pode acessá-la.
Teste uma restauração separadamente, com integrações ao vivo desabilitadas, e atualize as etapas de recuperação escrita.
Verifique software, armazenamento, backups, configurações de domínio e HTTPS antes de hospedar WordPress. Preparar um novo site ou planejar a migração e recuperação de um site existente.
Estimar armazenamento de hospedagem de arquivos do site, bancos de dados, mídia, registros e crescimento. Compare seus requisitos com o armazenamento do plano e as opções de espaço disponíveis.