Introducción
PAPER & FORM tiene cuatro pedidos, pero su backup guardado termina en R-103. Debes abrir el estado anterior junto a la tienda original, revisar sus artículos y demostrar que el servicio restaurado puede aceptar un pedido de prueba de forma independiente.
Este laboratorio empieza por separado. La base original y backups/cutoff.dump ya están preparados con el mismo punto de tres pedidos del recorrido anterior. Se necesita familiaridad básica con la terminal; los conceptos de base y conexión se explican de nuevo. Usa Workstation para los comandos, Original Shop para el servicio original y Restored Copy para el destino de prueba.
Solo puedes restaurar y reiniciar la base desechable shop_copy. Conserva el origen, el programa preparado, el backup y el archivo ajeno de uploads/. Todo es ficticio; no hay pagos ni correos. Dos bases en una instancia de práctica demuestran exportación lógica y aislamiento, no recuperación completa ante desastres, redundancia física ni PITR.
Restaurar solo en el destino independiente vacío
En este paso abrirás una copia funcional de los pedidos límite. Abre Original Shop y después Orders. Hay cuatro registros, R-101 a R-104. Abre R-103: Rae tiene dos Print pair con total $36.00. R-104 pertenece a Sol y se añadió después del punto guardado. Debe conservarse en el original y quedar fuera del archivo restaurado.
Abre Restored Copy. La franja color óxido indica shop_copy. La portada funciona, pero Orders explica que la base independiente está vacía. Una respuesta de la portada no demuestra la restauración de una tienda.
Cambia a Workstation. pwd muestra el directorio actual:
pwd
/home/labex/project/shop-backup
./shopctl identity lee las conexiones reales. Los servicios guardados seleccionan base, host, puerto y cuenta: shop-source conecta a shop_source como d09_reader de solo lectura; shop-copy conecta a shop_copy como d09_copy escribible. Comparten servidor en 127.0.0.1:5432, pero el rol de la copia no puede conectarse al origen:
./shopctl identity
pg_restore --list lee el archivo personalizado sin escribir en una base. Comprueba el nombre de origen y las entradas orders y order_items:
pg_restore --list backups/cutoff.dump
Una base guarda registros estructurados; los artículos están relacionados con su pedido. Los archivos personalizados incluyen definiciones, datos, secuencias para nuevos identificadores y restricciones que conservan esas relaciones. Se restauran con pg_restore, no enviando el binario a psql. Los clientes preparados de exportación y restauración son PostgreSQL 14.
La acción empty del asistente imprime la identidad real del destino y rechaza bases con tablas o secuencias de usuario. Un destino no vacío podría contener trabajo que debes preservar. No uses --clean ni --create: pueden borrar objetos existentes o usar el nombre original de la base archivada.
En el comando siguiente, && ejecuta la parte derecha solo si aprueba la comprobación de vacío. --dbname=service=shop-copy selecciona explícitamente el destino independiente. --no-owner --no-privileges evita importar las cuentas y concesiones originales. --single-transaction trata la importación como una unidad y revierte un fallo. --exit-on-error detiene el proceso en el primer error de base de datos. Ejecuta el comando protegido completo:
./shopctl empty && pg_restore --dbname=service=shop-copy --no-owner --no-privileges --single-transaction --exit-on-error backups/cutoff.dump
Espera la identidad del destino seguida de EMPTY: restore may proceed. Normalmente pg_restore no imprime nada si funciona. Si al repetir aparece REFUSED: target is not empty, puede que la primera importación ya funcionara: examina la copia antes de reiniciarla.
records copy lee los pedidos y artículos relacionados reales:
./shopctl records copy
Deben estar R-101, R-102 y R-103, con total $98.00, sin R-104. En Restored Copy abre Orders, R-103 y su recibo. Deben verse los dos Print pair y $36.00. Revisa Original Shop: todavía contiene R-104 de Sol y suma $124.00 entre sus pedidos.
Si elegiste un archivo incorrecto o necesitas reintentar una restauración fallida, reinicia solo el destino desechable del curso. El asistente muestra su identidad y exige el nombre exacto. Este comando es una recuperación opcional, no un paso rutinario después del éxito:
./shopctl reset-copy shop_copy
Descarta únicamente shop_copy. Después repite la restauración protegida. Nunca reinicies ni borres el original ni uses limpiezas generales de bases. La comprobación observa tu copia real; no la restaura por ti.
Demostrar que la copia escribe sin cambiar el original
En este paso probarás una escritura real en la copia. Una página de solo lectura puede parecer correcta aunque estén rotas las secuencias, relaciones o conexiones de escritura. Harás un pedido real de prueba en la copia independiente y compararás las tiendas. Quédate en Restored Copy, abre Collection y baja al formulario. Antes de enviar, lee Writing to: shop_copy · RESTORED COPY y la franja color óxido. No envíes esta prueba en Original Shop.
Introduce exactamente:
| Campo | Valor |
|---|---|
| Reference | R-901 |
| Name | Copy test |
| Item | Print pair |
| Quantity | 1 |
Selecciona Place order ↗. R-901 contiene un artículo y total $18.00. Descarga el recibo y comprueba que nombra shop_copy. El pedido usa la secuencia y la relación de clave foránea restauradas; no insertaste una página preescrita. Repetir la misma referencia devuelve Already recorded en lugar de crear otro pedido.
Abre Orders en esta misma copia. Deben estar R-101, R-102, R-103 y R-901, sin R-104. Cambia a Original Shop y abre Orders. Sigue teniendo R-101 a R-104, sin R-901. Dos franjas diferentes no bastarían si ambas aplicaciones escribieran en la misma base.
En Workstation, muestra las identidades y lee los dos conjuntos reales:
./shopctl identity
./shopctl records copy
./shopctl records source
La copia suma $116.00; el origen sigue en $124.00. Sería incorrecto exigir que todas las filas fueran siempre iguales: R-104 corresponde solo al origen posterior, y R-901 solo a la copia restaurada. Compara los registros compartidos hasta el límite y las diferencias permitidas de cada lado.
El formulario original rechaza R-901 sin escribirlo. Si elegiste la pestaña equivocada, lee Check the destination, cambia a Restored Copy y envía allí. También se rechazan referencias desconocidas; corrige el formulario y reintenta. Si un R-901 existente tiene nombre, artículo o cantidad erróneos, ./shopctl correct copy R-901 muestra el destino real y corrige solo ese pedido a Copy test / Print pair / 1. Los demás pedidos de la copia y todos los datos del origen quedan intactos. Si solo la copia desechable necesita un reintento limpio, usa exactamente la recuperación reset-copy shop_copy del paso 1, restaura otra vez y añade una sola vez el pedido de prueba.
La comprobación final lee las bases y sitios activos, conserva el archivo subido ajeno y prueba el archivo en otra base desechable. No crea el pedido de prueba ni repara tu copia. Tu backup ya tiene evidencia de datos completos, un límite claro y una restauración independiente y escribible.
Resumen
Identificaste el origen y destino reales, protegiste un destino vacío, restauraste un archivo personalizado en una transacción y leíste pedidos completos. El nuevo pedido exclusivo de la copia demostró un servicio independiente y escribible mientras el original conservó su pedido posterior. Es un ensayo de restauración lógica, no toda una estrategia de recuperación de producción.
