We currently operate under the assumption that the pre-deploy backup will be a restore point in the unlikely scenario where we notice data corruption or failures on a production site (eg. failed updates). Further to this assumption the process is assumed to just be a drush command to import the database again. The workflow and the limits of this process are neither tested nor documented.
Proposed solution
Introduce a db restore script as part of the scaffold tooling that is supported by functional and practical tests. The script should perform basic validation and allow one line restore command that accepts .sql, .sql.gz and .tar.gz backups.
Usage
../govcms-db-restore [path-to-file] e.g. vendor/govcms/govcms-tooling/scripts/deploy/govcms-db-restore /tmp/backup.tar.gz
Issue
We currently operate under the assumption that the pre-deploy backup will be a restore point in the unlikely scenario where we notice data corruption or failures on a production site (eg. failed updates). Further to this assumption the process is assumed to just be a drush command to import the database again. The workflow and the limits of this process are neither tested nor documented.
Proposed solution
Introduce a db restore script as part of the scaffold tooling that is supported by functional and practical tests. The script should perform basic validation and allow one line restore command that accepts
.sql,.sql.gzand.tar.gzbackups.Usage
../govcms-db-restore [path-to-file]e.g.vendor/govcms/govcms-tooling/scripts/deploy/govcms-db-restore /tmp/backup.tar.gz