Back up and practise restoring

A backup is useful when you can restore it

This lesson rehearses recovery in the local sample. It creates a new temporary database to test a backup and leaves the running store alone. Do not use it as a command to replace a live database.

Do the test-order lesson first. For this sample’s automated order-specific restore check, run the documented engineering verification during a quiet moment:

npm run verify

It creates a synthetic order, saves its ID for later checks, and restarts this sample’s services. It is unsuitable as a live-store monitoring command.

1. Create a backup

From the starter folder, run:

npm run backup

The command creates a PostgreSQL dump and a checksum in .local/backups. The checksum helps detect a changed or damaged file. Keep the filename, time, source version, and checksum in your maintenance log. Do not open the dump in AI chat or send it as an ordinary support attachment.

2. Rehearse a restore

npm run restore:check

The script restores the backup into a separate temporary database, checks the sample products and most recently verified order, and removes that temporary database. It does not overwrite the shop you are using.

Read the backup and restore documentation in this starter. Create a
database backup, then run the isolated restore rehearsal. Report only
the filename, checksum, restore result, whether the recorded test order
was found, and whether the temporary database was removed.
Never print rows, private settings, or credentials. Preserve the running
database. If a check fails, stop and explain the failed check without
deleting the original store or calling the backup verified.

3. Know what this does and does not save

Item	Covered by this sample’s database dump?
Products and persisted orders	Yes, in PostgreSQL.
Theme and included illustrations	No; keep the matching source version separately.
Private settings	No; keep an encrypted copy under your control.
Future uploaded media	No; requires a separate media backup.
Redis jobs and third-party systems	No; need their own recovery plan and reconciliation.

Keep an encrypted backup copy outside the server you are protecting. A file on the same disk will not help if that disk is lost. Decide your acceptable data loss window and restore time before setting a schedule; this sample does not promise either.

4. Understand the live-store recovery risk

Restoring an old database can remove orders recorded after that backup, while a payment provider still remembers their payments. Before any live replacement, stop and get a recovery plan that preserves the current data, identifies the missing interval, and reconciles orders against provider records.

Never ask AI to “restore yesterday’s backup” without that plan. A successful isolated rehearsal is evidence about the backup, not permission to discard newer transactions.

If the rehearsal fails

Keep the dump, checksum, source version, and non-sensitive error. Check which backup the script used and whether the recorded verification order was expected in it. Do not delete the only backup. Ask for help with the specific failure.

Ready when

The isolated restore passes, the recorded order can be found, the original store still works, and you know which assets need separate protection. Keep the result in your maintenance log.