Elegir una copia fiable y restaurar el sitio

Introducción

Una pequeña tienda usa un servicio de pedidos para relacionar clientes, productos y cantidades. Tras un incidente preparado faltan dos pedidos. Debes recuperar los datos necesarios sin reemplazar el catálogo público independiente. Todas las personas y registros son sintéticos; no hay malware.

Un backup es una copia para recuperación. Un archivo agrupa ficheros y una suma de comprobación resume sus bytes. Aprenderás por qué la suma solo ayuda si su referencia es fiable y restaurarás una base SQLite real mediante una zona de preparación. Es una recuperación acotada, no un procedimiento completo de respuesta a incidentes.

Solo necesitas introducir comandos y cambiar de pestaña. Workstation y App Server son sesiones distintas del mismo equipo de formación, con directorios iniciales distintos; no son máquinas separadas. Usa Order Service para la vista web.

Conservar los datos dañados del servicio

En este paso comprenderás los datos de negocio que faltan y conservarás una copia para revertir antes de modificar el servicio.

Abre Order Service. Normalmente cada fila relaciona un número de pedido con un cliente, estado, producto y cantidad. El punto de recuperación requerido contiene estos tres pedidos:

Ahora solo aparece 4101. Pulsa Public catalog: aún debe listar tazas, cuadernos y bolsas. Esta carga no pertenece a la base y debe sobrevivir a la recuperación. Después vuelve a la página de pedidos.

Una API es la interfaz del servicio para programas. En Workstation, curl solicita la API; -f considera los errores del servidor como fallos, -s oculta el progreso y -S mantiene visibles los errores. 127.0.0.1 indica este mismo equipo y 8080 es el puerto.

curl -fsS http://127.0.0.1:8080/api/orders

El resultado es un array JSON, una lista de filas entre corchetes. Solo está la fila de Mina. Una solicitud exitosa no significa que los datos estén completos.

Cambia a App Server. pwd muestra el directorio actual:

pwd

Espera /srv/order-service. SQLite guarda las tablas en orders.db. Este servicio preparado no tiene escritores y abre la base de nuevo en cada solicitud; aquí es seguro copiarla. Una base de producción ocupada necesita un procedimiento de copia coherente con la aplicación.

cp recibe primero el origen y luego el destino. Conserva la base actual fuera del directorio de la aplicación para poder revertir una restauración errónea:

cp /srv/order-service/orders.db /home/labex/project/recovery/damaged-before-recovery.db

La ausencia de salida suele indicar que terminó la copia. No repitas el comando tras restaurar: sobrescribirías la copia de reversión con la base recuperada. Has conservado el estado dañado; el servicio sigue pendiente de recuperación.

Seleccionar un archivo de recuperación fiable

En este paso rechazarás bytes alterados y colocarás el archivo verificado adecuado en un directorio de preparación.

Cambia a Workstation. cd cambia de directorio y ls lista su contenido. Una ruta absoluta empieza por / y funciona desde cualquier directorio actual.

cd /home/labex/project/recovery/backups

ls

Hay tres archivos .tar.gz: tar agrupa ficheros y gzip los comprime. Los nombres describen horas de recuperación; el más reciente no es necesariamente seguro ni adecuado.

cat muestra un fichero de texto. Lee los puntos de recuperación suministrados por separado por el custodio:

cat /opt/backup-custodian/recovery-points.txt

El archivo 0800 es anterior a 4102 y 4103. El 0900 incluye el punto requerido. El candidato 1000 es posterior, pero aún requiere una comprobación de integridad.

Integridad significa que los bytes no cambiaron respecto de una referencia. SHA-256 genera un resumen para comparar. El manifiesto del custodio pertenece a root y está fuera de la carpeta de recuperación editable normalmente. Se supone que llegó por un canal protegido independiente; no se enseñan firmas ni distribución de claves. El administrador puede eludir la propiedad local, por lo que este equipo didáctico no es un ancla de confianza inviolable.

sha256sum -c lee pares de nombres y resúmenes y compara los ficheros del directorio actual. Usa el manifiesto independiente:

sha256sum -c /opt/backup-custodian/SHA256SUMS

0800 y 0900 deben indicar OK; 1000, FAILED. La salida no nula y la advertencia son intencionadas: al menos un archivo cambió. No extraigas ese candidato.

El manifiesto adyacente puede editarse junto con las copias. Compara su resultado:

sha256sum -c SHA256SUMS

Los tres indican OK. Quien altera un archivo puede sustituir la suma junto a él. Coincidir con un resumen no fiable no demuestra autenticidad. 0800 está intacto, pero le faltan registros. Elige 0900 porque está intacto y es adecuado.

La preparación permite examinar datos antes de tocar el servicio activo. mkdir -p crea el directorio y admite que ya exista:

mkdir -p /home/labex/project/recovery/stage

Copia allí el candidato verificado:

cp orders-0900.tar.gz /home/labex/project/recovery/stage/orders-0900.tar.gz

Si escribes mal el origen, cp indicará que no encuentra el fichero; usa ls y reintenta. El control examina los bytes reales del archivo preparado, no una afirmación escrita de verificación.

Examinar la base en preparación

En este paso examinarás los miembros del archivo, extraerás el único fichero esperado y leerás la base preparada sin modificarla.

En Workstation, entra en preparación:

cd /home/labex/project/recovery/stage

tar -tvzf lista un archivo comprimido con gzip: t lista, v incluye tipo y permisos, z indica gzip y f nombra el archivo. Listar no extrae nada.

tar -tvzf orders-0900.tar.gz

El único miembro debe ser orders.db, con permisos que empiezan por -, indicando un fichero regular. Detente si hay rutas absolutas, componentes .., enlaces o ficheros inesperados. Revisar nombres es útil aquí porque este archivo didáctico fiable contiene un fichero regular; no es una política completa de extracción segura para archivos arbitrarios. Nunca ejecutes programas de una copia sospechosa.

Para extraer usa x en lugar de t y omite v. El orders.db final limita la extracción a ese miembro; --no-same-owner conserva tu propia titularidad:

tar -xzf orders-0900.tar.gz --no-same-owner orders.db

SQLite guarda tablas relacionadas en un fichero. La herramienta preparada db-view abre la base en modo de solo lectura, comprueba coherencia interna y relaciones e imprime las filas de negocio unidas. No necesitas escribir SQL ni editar la base. Pásale la ruta preparada:

/opt/c11-runtime/db-view /home/labex/project/recovery/stage/orders.db

Espera Integrity: ok, Relationships: ok y los tres pedidos. Una base válida puede corresponder a otro punto; compara también clientes, estados y cantidades con el paso 1.

Una ruta incorrecta produce un error en vez de crear una base vacía. Comprueba pwd y ls y reintenta. Si los datos difieren, vuelve al manifiesto independiente, selecciona el archivo correcto y extrae otra vez. El sitio sigue dañado: la preparación por sí sola no restaura la aplicación.

Restaurar y probar el servicio activo

En este paso reemplazarás solo la base designada y confirmarás la recuperación mediante solicitudes reales, conservando la carga pública.

Cambia a App Server. La copia de reversión está fuera de este directorio y la base preparada ya pasó la inspección. Copia únicamente esa base a la ruta de datos designada:

cp /home/labex/project/recovery/stage/orders.db /srv/order-service/orders.db

Origen y destino son ficheros distintos. Evita copiar todo el directorio preparado sobre /srv/order-service: contiene cargas ajenas que deben conservarse. No hace falta reiniciar el demonio porque esta aplicación preparada de solo lectura cierra la base tras cada solicitud. Otras aplicaciones pueden exigir su procedimiento de mantenimiento o reinicio.

Consulta la aplicación en vez de confiar en la existencia de una copia o de un fichero restored:

curl -fsS http://127.0.0.1:8080/api/orders

Deben aparecer 4101, 4102 y 4103, con clientes correctos, estado packed y cantidades 1, 2 y 3. Abre Order Service y actualiza: la tabla debe coincidir.

Comprueba también la carga pública independiente:

curl -fsS http://127.0.0.1:8080/uploads/catalog.txt

Public catalog: mugs, notebooks, tote bags

Pulsa Public catalog en el navegador y confirma el mismo contenido. Recuperar significa devolver los datos requeridos y mantener el funcionamiento ajeno normal.

Si aparece Database unavailable, examina de nuevo la base preparada y repite la copia de un fichero con rutas absolutas correctas. Para volver al estado dañado original mientras investigas un error, usa la copia conservada:

cp /home/labex/project/recovery/damaged-before-recovery.db /srv/order-service/orders.db

Ese último comando deshace la recuperación intencionadamente. Si lo usas, repite la copia de la base preparada verificada a la activa antes de terminar. Conserva el fichero de reversión para revisarlo después.

Resumen

Conservaste una copia de reversión, comparaste bytes con un manifiesto independiente fiable, elegiste un punto adecuado e inspeccionaste una base SQLite preparada. Después restauraste el servicio real y comprobaste relaciones y una carga ajena. Reciente, intacto y adecuado son propiedades diferentes; una recuperación segura necesita combinarlas correctamente.