Runbook: restore from backup #

For system administrators who must bring a customer site back from a backup: after data loss, a broken update or a compromise. The procedure is that of 10.9 Backups and restore; this page arranges it for an incident.

Contents #

1. Decide first
2. Prepare
3. Restore
4. Verify and reopen
5. After the incident

Decide first #

Prepare #

1. Copy the current state aside (database dump and files), as above.

2. Maintenance mode on, so visitors get a 503 page and nobody publishes:

   php bin/php/maintenance.php on --message="Restoring the site" --until=1h --allow-root-user

3. Under Velocity, stop the server so no worker holds the old database:

   php bin/php/console exp:velocity stop --allow-root-user

Restore #

1. The database, with the tool of its engine (official order):

   Engine	Restore
   1. SQLite 3	sqlite3 var/storage/sqlite3/exponential.db ".restore '/backup/db.sqlite'"; never copy over a file in use
   2. PostgreSQL	pg_restore -U USER -d DATABASE --clean /backup/db.dump
   3. MongoDB	mongorestore --uri="..." --drop /backup/mongo
   4. MariaDB	mariadb -u USER -p DATABASE < /backup/db.sql
   5. Oracle	php bin/php/console ext:ezoracle:datapump --import=db.dmp, or Oracle's impdp
   6. MySQL	mysql -u USER -p DATABASE < /backup/db.sql

   Sources: 10.9 and Database support. -p makes the client ask for the password; never write it on the command line.

2. The files: unpack var/storage (and var/<site>/storage), and if needed settings/override and settings/siteaccess, over the installation.

3. Owners and modes: the files must belong to the site's user as the engine or PHP-FPM pool expects (Writable directories and permissions).

4. Caches and autoloads:

   php bin/php/ezcache.php --clear-all --allow-root-user
   php bin/php/ezpgenerateautoloads.php -e

5. Start Velocity and clear its response cache:

   php bin/php/console exp:velocity start --allow-root-user
   php bin/php/console exp:velocity cache clear --apply --allow-root-user

   Under PHP-FPM, reload the site's PHP-FPM service.

Verify and reopen #

1. Open the front page and the administration through a hosts-file entry or with maintenance mode letting your address through (--allow-ip, see Maintenance mode).

2. Sign in, open recently changed content, upload a test image, run a search.

3. Check var/log/error.log for new errors: ./console exp:logs --tail=var/log/error.log --lines=50.

4. Maintenance off:

   php bin/php/maintenance.php off --allow-root-user

After the incident #

• To do: Tell the customer what was restored, from which time, and what must be published again.
• To do: If the search index looks incomplete, rebuild it (php bin/php/updatesearchindex.php; see Search backends).
• To do: Record how long the restore took: that is your real recovery time for the SLA (SLA options).
• To do: Keep the copy of the damaged state as long as your policy says, then delete it.

Related pages #

• Restore and restore tests
• Database backups per engine
• Compromised site
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.