tai-sql backup y tai-sql restore

tai-sql backup [-s <schema>] [-F custom|sql] [--schema-only | --data-only] [-l]
tai-sql restore [FILENAME] [-s <schema>] [--latest] [--clean] [-d]

Usan la herramienta nativa del motor (pg_dump / pg_restore en PostgreSQL), que tiene que estar instalada en el sistema. Necesita el extra backup:

pip install 'tai-sql[backup]'
sudo apt install postgresql-client

Crear un backup

tai-sql backup                    # formato del datasource, estructura y datos
tai-sql backup -F sql             # texto plano legible
tai-sql backup --schema-only      # solo estructura
tai-sql backup --data-only        # solo datos
tai-sql backup --list             # qué backups hay

Formato	Qué es
custom (por defecto)	Binario comprimido. Más pequeño, y restore puede ser selectivo
sql	Texto plano. Se puede leer y editar, y restaurar con el cliente del motor

Restaurar

tai-sql restore --latest          # el último backup disponible
tai-sql restore mi_backup.dump    # uno concreto
tai-sql restore --latest --clean  # elimina los objetos existentes antes de restaurar
tai-sql restore --latest -d       # qué haría, sin ejecutar

--clean elimina antes de restaurar

Si el backup está incompleto o corrupto, te quedas sin lo uno y sin lo otro. Comprueba siempre con -d primero.

Configuración

Va en el datasource() del schema:

datasource(
    provider=env('MAIN_DATABASE_URL'),
    backup_storage=...,          # origen de tai-storage donde se guardan
    backup_format='custom',      # 'custom' | 'sql'
    backup_retention=10,         # cuántos conservar; None = sin límite
    restore_provider=env('STAGING_DATABASE_URL'),
)

Por defecto los backups se guardan en .database_backups/{schema}/ del proyecto.

restore_provider es lo que permite restaurar un backup de producción contra otra base de datos: si no se declara, el restore se ejecuta contra el mismo provider del que salió el backup, que casi nunca es lo que quieres para probar una restauración.