Alojamiento y restauración: construir un plan de recuperación
Planifique hospedaje de copias de seguridad alrededor de archivos, bases de datos y pérdida de datos aceptable. Comprenda los puntos de restauración semanales o diarios y la recuperación de pruebas lejos de su sitio web en vivo.
Elija cuánto trabajo reciente se puede permitir perder
Comience con los datos que cambian: contenido del sitio web, cargas, registros de bases de datos, órdenes de almacenamiento y configuración de aplicaciones. Decide cuánto trabajo reciente podría reconstruir después de un fracaso. Una cartera raramente editada y una tienda que recibe pedidos durante todo el día pueden necesitar diferentes planes de recuperación.
Compare esa necesidad con el programa de respaldo que elija. Si se producen cambios importantes entre las copias programadas, decida cómo las conservará. Un horario diario no significa que cada transacción sea recuperable continuamente, y una opción de respaldo no es una garantía de un tiempo de recuperación particular.
Frecuencia de copia de seguridad descontinuada de la retención de puntos de restauración
El configurador VPSLibre no ofrece respaldos adicionales, respaldos semanales o respaldos diarios. La opción semanal describe una copia de seguridad por semana con siete puntos de restauración; la opción diaria describe uno por día con siete puntos de restauración. Estas son opciones de servicio solicitadas, con sus propias líneas de cotización cuando se seleccionan.
Siete puntos de restauración son siete copias retenidas, no una promesa universal de siete días. Sus fechas y cobertura utilizable dependen del horario elegido y de copias con éxito completadas. Después de la entrega, verifique la información de copia de seguridad real, los datos cubiertos, donde se guardan copias y cómo se solicita la recuperación antes de depender del servicio.
Sin una opción adicional de copia de seguridad, gestiona su propio plan de respaldo. Almacenamiento adicional de servicio es una opción separada y no crea copias de seguridad. Mantenga una copia independiente de datos importantes para que su recuperación no dependa de una cuenta o un entorno.
Hacer que cada conjunto de recuperación sea completo e identificable
Una recuperación WordPress normalmente necesita tanto archivos como la base de datos. Subidas, temas, plugins y configuración en vivo en archivos, mientras que publicaciones, configuraciones y otros datos de aplicaciones también viven en la base de datos. La descarga del directorio web por sí sola no suele capturar su base de datos.
Para cualquier aplicación, lista los datos y la configuración necesarios para recrear un entorno de trabajo. Archivos compatibles de grupo y exportaciones de bases de datos para el momento en que representan. Grabar la versión de la aplicación y los requisitos ambientales pertinentes, y proteger copias que contengan credenciales o datos personales.
Compruebe el alcance de una copia de seguridad de servicio en lugar de asumir que incluye cada dependencia externa. Los datos de un servicio de terceros necesitan sus propios arreglos de recuperación. Una copia sincronizada que reproduce inmediatamente las eliminaciones también puede ser insuficiente cuando necesita una versión anterior.
Restauración de pruebas lejos del sitio web en vivo
Prepare un entorno separado con los requisitos necesarios para el conjunto de recuperación elegido. Restaurar las copias utilizando las herramientas apropiadas para su aplicación y el acceso realmente disponible. Use credenciales separadas y restrinja el acceso a datos personales o de clientes restaurados.
Evitar que el entorno de prueba envíe correos electrónicos reales, cargando a los clientes o ejecutando integraciones en vivo. Verificar páginas representativas, medios de comunicación, logins y registros de bases de datos. Para una tienda, compruebe que los datos de pedido recuperados corresponden al punto esperado en el tiempo sin iniciar transacciones reales de clientes.
Grabar lo que funcionó, lo que faltaba y cuánto tiempo tomó su propia prueba. Esa observación ayuda a mejorar su plan de recuperación; no es una garantía publicada de tiempo de restauración. Mantenga intacto el ambiente vivo mientras resuelve fallos de prueba.
Restaurar WooCommerce sin descartar nuevas órdenes
Restaurar una base de datos de tienda más antigua puede eliminar pedidos, clientes o cambios de stock creados después de esa copia de seguridad. Grabar el punto de recuperación e identificar lo que cambió desde antes de reemplazar los datos en vivo. Los registros del proveedor de pagos están separados de la base de datos del sitio web; una pantalla de orden restaurada no establece que esos dos registros estén de acuerdo.
Ensayar la restauración en una copia aislada con integraciones externas contenidas. Acorde sobre cómo se conciliarán las transacciones recientes y quién puede autorizar la reapertura. Para un problema de código o extensión, primero establezca si un rollback específico puede resolverlo sin reemplazar toda la base de datos de la tienda. Un producto CSV no es una copia completa de pedidos, clientes o registros de suscripción.
Grabar el tiempo de copia de seguridad y la última referencia de pedido en vivo.
Identificar pedidos, clientes y cambios de stock después de ese punto.
Reconcile los registros de pago y cumplimiento antes de reabrir el checkout.
Verifique la aplicación restaurada y mantenga el registro de reconciliación.
Retrocede los volúmenes Docker Compose como datos de aplicación
Mantenga la configuración de Compose y un inventario de volúmenes nombrados, monturas de bind, exportaciones de bases de datos y subidas. Recrear contenedores de sus imágenes restaura el código, no los registros mantenidos en esas rutas de datos. Utilice el procedimiento de copia de seguridad compatible con la base de datos o la aplicación para obtener un conjunto consistente; copiar un volumen en vivo sin ese procedimiento no es una copia de seguridad de la base de datos verificada.
Restaurar en un proyecto aislado con nombres de volumen y destinos separados. Recrear los servicios aprobados, comprobar la propiedad y la configuración, luego el representante de prueba lee y escribe contra los datos restaurados. Grabar la versión y el tiempo de instantánea usado. Evite señalar el ensayo en los datos de producción o las integraciones al revisar la recuperación.
Mantenga el plan de recuperación utilizable a medida que el proyecto cambia
Revise el plan cuando agregue una base de datos, mueva archivos, cambie el software o introduzca una nueva integración. Haga una copia recuperable antes de un cambio importante de aplicación y verifique que las instrucciones de recuperación aún coinciden con el medio ambiente. Utilice la información real de gestión de servicios para cualquier procedimiento específico del proveedor.
Antes de reemplazar los datos vivos, decida qué cambios más recientes deben ser preservados y quién puede aprobar la operación. Para una tienda ocupada, una base de datos más antigua puede omitir órdenes más nuevas. Identificar el punto de recuperación requerido y una ruta de devolución antes de que un administrador realice la restauración en vivo.
Grabar los datos para proteger y la ventana de pérdida aceptable.
Confirme el horario seleccionado, los puntos de restauración retenidos y el alcance real de la copia de seguridad.
Mantenga archivos completos, bases de datos y conjuntos de configuración con fechas identificables.
Almacene una copia protegida independiente y verifique quién puede acceder a ella.
Pruebe una restauración por separado, con integraciones en vivo desactivadas, y actualice los pasos de recuperación escritos.
Compruebe el software, almacenamiento, copias de seguridad, configuración de dominio y HTTPS antes de hospedar WordPress. Prepare un nuevo sitio web o planifique la migración y recuperación de un sitio existente.
Estimación de almacenamiento de alojamiento de archivos web, bases de datos, medios de comunicación, registros y crecimiento. Compare sus requisitos con el almacenamiento del plan y las opciones de espacio disponibles.