Backups

Every update backs up the database before it changes anything. You can also take a backup yourself and restore one.

What is backed up

The whole Nikto Platform database: projects, scans, findings, the activity log, stored responses, settings, installed licenses, and the operator login account.

It does not include .env, the compose file, or the Docker images.

Backups contain sensitive data

A backup holds everything your scans found and every credential stored in the product: proxy and scan credentials and the operator login hash. Treat backup files like the database itself. Nikto Platform creates the backups folder readable by your user only (0700) and each file readable by your user only (0600). Keep those permissions if you copy a backup elsewhere.

On Windows those modes do not apply: access is set by the folder's ACLs, which the backups folder inherits from the launcher install folder under your %AppData%. Check that no other account can read it.

Never include the backups folder when you zip, copy, or share the install folder, for example to send it with a support request. Leave it out, or remove it from the copy first.

Where backups are kept

Backups are kept in the backups folder inside the launcher install folder.

File names say what made the backup and when, in UTC:

File	Made by	Kept
pre-update-YYYYMMDD-HHMMSS.dump	every update	The newest 3. Older ones are deleted after a new one succeeds, and the update prints which.
manual-YYYYMMDD-HHMMSS.dump	you, with the backup command	Until you delete them
pre-restore-YYYYMMDD-HHMMSS.dump	a restore, just before it replaces the data	Until you delete them

Each file is a PostgreSQL custom-format dump (pg_dump -Fc). Every backup is checked by reading the whole file back with pg_restore before it counts. A backup that fails the check is deleted and reported as an error. Temporary files left by an interrupted backup (.*.dump.partial) are removed by the next backup.

Deleting the launcher install folder deletes its backups too. Copy any you want to keep somewhere else first. nikto-launcher uninstall deletes the folder too, but first offers a final backup to a path outside it (your Downloads folder by default).

Backups during updates

nikto-launcher update pulls the new images, back up the database, and only then recreate the containers. The backup is taken from the database that is still running the old version. If the database container is stopped, the update starts that same container for the backup; it never creates a new one from the images it just pulled.

• Fresh install: there is no database yet, so there is nothing to back up. The update says so and continues.

• The backup fails: the update stops before any container is recreated. At most, the existing database container was started to take the backup. The error names the file, the step that failed, and what PostgreSQL reported. Fix the cause (usually disk space) and run the update again.

• The stack was taken down (nikto-launcher down, or docker compose down) so no database container exists: the update stops rather than create one from the new images. Take a backup with the backup command below (it creates the database container), then run the update again.

• Update without a backup: only if you must. Pass the option explicitly:

  nikto-launcher update --no-backup

Disk space

Before each backup, the database size is printed. If the free space in the backups folder is less than twice the database size, the backup is refused and the message shows both numbers. A backup file is compressed and is usually much smaller than the database.

On Windows the launcher cannot check free space. It prints a note instead, and the backup goes ahead.

Take a backup

nikto-launcher backup

The command prints the new file's path and size. It starts the database container if it is not running. The rest of the stack is not touched.

Restore a backup

Restoring replaces all current data

A restore replaces all current data (projects, scans, findings, settings, licenses, and the operator login) with the contents of the backup. Anything created after the backup was taken is gone, except in the safety backup described below.

nikto-launcher restore <file>

<file> can be a path, or just a file name from the backups folder. Run the command without a file to list the available backups.

The restore:

1. Checks the whole file. A damaged, truncated, or wrong file is refused before anything is stopped. The database container is started for this check if it was not running, and is left running.
2. Asks you to confirm, and shows the date of the backup. The default answer is No. --yes skips the question.
3. Stops the api and ui services, so nothing changes after the next step.
4. Saves the current data to pre-restore-YYYYMMDD-HHMMSS.dump. If this safety backup fails, api and ui are started again and nothing is restored. --no-backup skips it.
5. Loads the backup in a single database transaction.
6. Starts the stack again. If the backup came from an older release, the API brings the database up to date when it starts.

If loading the backup fails, the transaction is rolled back, so the database most likely still has the data it had before. Check it before you restart. The api and ui services stay stopped on purpose. The error shows the safety backup's path and the command that starts the stack again. If the error mentions a lock timeout, something other than the stack is connected to the database and holding a lock; close it and try again.

The operator login comes from the backup. After a restore, sign in with the account and password that existed when the backup was taken.

Next steps

• Host Commands — full flag reference for backup and restore
• Docker Deployment — install, update, and uninstall
• Operator Login — reset a password you no longer know
• Support bundle — diagnostics to attach to an issue (never includes backups or database contents)