Qué promete el sistema
Una copia es candidata a recuperación hasta demostrar que restaura un servicio útil. Acuerde cuánto trabajo reciente puede reintroducirse y cuánto tiempo puede estar parado el servicio. Son decisiones operativas del responsable, no promesas que surgen del calendario de copias.
Comparar opciones prácticas
Liste base de datos, archivos, configuración, acceso a secretos y versión compatible de la aplicación. La base sola puede no reconstruir el producto. Use un método adecuado para escrituras activas. SQLite documenta una API de copia consistente; copiar un archivo en uso sin entender su journal no constituye un procedimiento suficiente.
Probar el recorrido completo
Imagine restaurar pedidos en un entorno aislado. Compruebe integridad, pedidos representativos y adjuntos. Arranque con integraciones salientes desactivadas para no reenviar avisos ni cobrar durante el ensayo. Mida desde obtener la copia hasta completar una tarea normal. Permisos o configuración ausentes son defectos de recuperación aunque la base abra.
Hacer visible la recuperación
No ensaye sobrescribiendo la única producción. Proteja el sistema actual, identifique el destino exacto y exija una acción deliberada al reemplazar datos. Una copia en el mismo disco no cubre perderlo. Pruebe acceso a la copia separada y sus claves; un archivo irrecuperable no sirve.
Escribir la recuperación antes del incidente
Empiece por objetivo y destino: ensayo aislado, host perdido o sustitución de producción dañada. Las consecuencias difieren. Registre origen, fecha, integridad y versión compatible. Separe instrucciones de acceso y secretos para compartir el procedimiento sin difundir credenciales.
Antes de sustituir producción, controle cuándo paran las escrituras: web, trabajadores, tareas programadas y otros procesos. Preserve el estado actual cuando sea posible y útil. Restaure al lugar previsto, compruebe propietario, permisos, base y archivos antes del tráfico. Reactive en orden que no ejecute la cola sobre datos incompletos o incompatibles. Ensaye con el despliegue real, sin improvisar comandos en la caída.
Después, concilie pedidos recientes, adjuntos y referencias de pago con el punto recuperado. El trabajo posterior necesita responsable. No repita cobros, envíos o mensajes solo porque el registro local volvió atrás: el exterior no se restauró con la base. Mantenga diferencias visibles y explique su impacto a atención. Actualice el procedimiento con tiempo, problemas de acceso y dependencias faltantes. Pruebe también retención y acceso a una copia separada; una restauración local perfecta no prueba sobrevivir a perder el host.
Pruebas de recuperación
| Etapa | Qué demostrar |
|---|---|
| Elegir copia | Identidad, creación, integridad y destino son inequívocos. |
| Detener escrituras | Se controlan todos los escritores y se conserva el estado previo cuando es viable. |
| Abrir servicio útil | La aplicación completa una tarea autorizada con archivos y configuración, no solo abre la base. |
| Conciliar el exterior | Se revisan trabajo posterior y acciones externas antes de reintentar, sin repetir actividad terminada. |
Ejemplos para la revisión
¿Quién restaura si falta el operador habitual? ¿Qué datos se perderán y cómo se concilian? ¿Qué dispara volver atrás? Lleve el último ensayo real, tiempo y brechas pendientes a la revisión, no solo un trabajo de copia en verde.
Fuentes y otras lecturas
Recuperación y mantenimiento
Un siguiente capítulo pensado para el software existente.
Hablemos de este servicio