Revisado · Recursos de Hosmio
Antes de empezar
Elija un destino desechable y un alcance de prueba escrito. Confirme el acceso al código de la aplicación, las versiones de software requeridas y el material de respaldo aprobado. Mantenga el destino separado de producción, con notificaciones salientes, tareas programadas y escrituras externas deshabilitadas hasta que se prueben deliberadamente.
01
Enumere qué debe migrarse y qué debe recrearse.
Incluya el entorno de ejecución, la base de datos, los archivos cargados, la configuración, las tareas programadas, los certificados, la propiedad del DNS y las integraciones externas. Registre quién controla cada dependencia y cómo se puede recuperar el acceso si el VPS actual no está disponible. Identifique cualquier característica específica del proveedor que necesite un reemplazo en lugar de una copia de archivo.
Anote las versiones y extensiones esperadas. Un comando de instalación que obtiene lo más reciente de hoy puede no recrear la aplicación que opera. Consulte el almacenamiento protegido de secretos para las credenciales; un plan de recuperación debe explicar cómo una persona autorizada las obtiene sin poner los secretos en el propio plan.
02
Elija un método de exportación y restauración que tenga en cuenta los datos.
Para PostgreSQL, una exportación lógica con pg_dump abarca una sola base de datos, mientras que los objetos globales como los roles necesitan un tratamiento aparte. La herramienta se niega a volcar un servidor de una versión principal más reciente que la que admite el cliente. La documentación oficial también advierte contra tratar pg_dump como una estrategia universal de copia de seguridad de producción habitual. PostgreSQL: pg_dump ↗
Elija el método apropiado para su aplicación y necesidades de recuperación junto con su operador. Registre lo que la exportación omite y cómo se mantienen los archivos coherentes con las referencias de la base de datos. Un comando que devuelve éxito es una primera comprobación útil, no la prueba de que se haya conservado una aplicación completa.
03
Restaure en un destino explícitamente separado.
Inspeccione el archivo y el destino antes de restaurar. La restauración de archivos de PostgreSQL utiliza pg_restore; las opciones que limpian objetos existentes pueden eliminar datos, y su comportamiento predeterminado puede continuar tras errores de SQL. Planifique el manejo de errores e inspeccione el resultado en lugar de asumir que se restauró cada objeto. PostgreSQL: pg_restore ↗ No ejecute un tutorial contra la base de datos de producción solo porque su nombre le resulte familiar.
Para las copias de seguridad de archivos, seleccione la instantánea prevista y un destino de prueba vacío. Restic documenta que la restauración puede sobrescribir archivos existentes; una sobrescritura interrumpida puede dejar un resultado parcial. restic: restaurar desde copia de seguridad ↗ Registre la instantánea de origen y la ruta de destino en la nota del ejercicio. Estas son directrices de selección de método, no comandos ejecutados ni verificados contra un VPS de Hosmio.
04
Verifique las tareas del usuario y los efectos secundarios ocultos.
| Comprobación | Evidencia que conservar | Resultado |
|---|---|---|
| La aplicación inicia con las versiones documentadas | Inventario de versiones y resultado de inicio | Aún no probado |
| Los registros y archivos representativos coinciden | Comprobaciones de registros sintéticos y adjuntos | Aún no probado |
| Los permisos se comportan correctamente | Dos roles de prueba y acceso esperado | Aún no probado |
| Los trabajos no envían trabajo externo duplicado | Acciones salientes deshabilitadas o prueba controlada | Aún no probado |
| Un operador sustituto puede seguir las notas | Recorrido independiente y lagunas | Aún no probado |
Utilice cuentas sintéticas y registros de prueba inofensivos siempre que sea posible. Verifique los límites de acceso, así como las lecturas exitosas. Una aplicación que inicia pero otorga los permisos incorrectos no es una recuperación exitosa. Mantenga las comprobaciones fallidas en el registro con un responsable para su remediación.
05
Planifique el punto en el que las nuevas escrituras cambian la decisión.
Un ensayo debe informar la secuencia del traslado futuro: paso final de consistencia, comprobaciones en el destino, conmutación de tráfico, decisión de aceptación y retirada del servicio antiguo. Decida quién puede detener o revertir la operación. Si el destino ha aceptado nuevas escrituras, enviar a los usuarios de vuelta a una copia antigua puede perder o dividir esas escrituras; la reversión necesita un plan de datos, no solo un cambio de DNS.
Prevea solapamiento en el presupuesto. Pueden ser necesarios un segundo servidor, almacenamiento independiente, cargos de tráfico, licencias y tiempo del operador. No asuma que un proveedor prorratea el VPS ni que los fondos prepagados son reembolsables. Los precios por periodo publicados de Hosmio describen términos por adelantado; no definen un servicio de migración ni de reembolso.
06
Deje evidencia que otro operador pueda usar.
Registre la fecha del ejercicio, las versiones, los identificadores de copia, el destino, el esfuerzo transcurrido y los resultados solo después de que el ejercicio se haya realizado realmente. Hasta entonces, use «planificado» o «no probado». Mantenga la hoja de aceptación con las notas de recuperación y enumere las dependencias que aún impiden una reconstrucción independiente.
Si el ensayo falla, clasifique la laguna: datos faltantes, software incompatible, credenciales no disponibles, una dependencia externa o un procedimiento poco claro. Resuelva el problema bloqueante más pequeño y luego repita la comprobación afectada. No declare la aplicación portátil mientras una tarea crítica siga sin probarse.
Conecte el plan con responsabilidades operativas con nombre y el proceso de aprobación de cambios del cliente. El resultado previsto es una capacidad demostrada de recuperarse dentro de un alcance documentado, no una promesa de cero interrupciones ni una migración entregada automáticamente.