Manage Backups

For: owners and admins who manage the InvoiceScript installation. Covers: creating, downloading, restoring, and scheduling backups.

What backups include

Each backup is a ZIP file containing:

• Database: a full copy of your database (SQLite file copy or MySQL dump)
• Media files: everything in storage/app/private/ and storage/app/public/ (uploaded files, attachments)
• Manifest: metadata including creation date, database driver, app version, and PHP version

Backups are stored in storage/backups/ on your server.

Create a manual backup

1. Go to Settings > Backups.
2. Optionally enter a passphrase to encrypt the backup.
3. Click Create Backup Now.

The backup appears in the list with its filename, size, and creation date.

Download a backup

From the backup list, click Download next to the backup you want. The ZIP file downloads to your local machine.

Keep downloaded backups in a secure location separate from your server (external drive, cloud storage, or a different server).

Delete a backup

Click Delete next to a backup in the list. Confirm the deletion. Deleted backups cannot be recovered.

Restore from a backup

Restoring replaces your current database and media files with the contents of the selected backup.

1. In the Restore from Backup section, select a backup from the dropdown.
2. If the backup was encrypted, enter the passphrase.
3. Type your email address to confirm the restore.
4. Click Restore Backup.

During restore, InvoiceScript:

• Enters maintenance mode (visitors see a maintenance page)
• Creates a safety backup of your current state
• Restores the database and media files from the selected backup
• Exits maintenance mode

The safety backup ensures you can recover your pre-restore state if needed.

Restore risks

[!CAUTION] Restoring is a destructive operation. Understand these consequences before proceeding.

• Data loss: all invoices, customers, payments, and settings created after the backup was made are lost
• User accounts: users added after the backup will not exist in the restored database
• Session invalidation: your current session is invalidated — you will be redirected to the sign-in page after restore
• Invoice numbers: numbering sequences revert to the backup state; if invoices were issued after the backup, those numbers may be reused
• Audit trail: audit log entries created after the backup are lost

Testing restore safely

Do not test restore on your live production installation. Use a disposable copy instead:

1. Copy your entire InvoiceScript installation to a separate directory or staging subdomain
2. Copy the .env file and update DB_DATABASE to point to a separate copy of the database — do not reuse the production database connection. For SQLite, copy the .sqlite file to the new directory. For MySQL, create a new database and import a dump of the production data.
3. Copy the storage/ directory so uploaded files are included in the test
4. In the copy, create a backup via Settings > Backups
5. Make a small change in the copy (e.g., edit the company name)
6. Restore from the backup you created in step 4
7. Verify the company name reverted — the restore works correctly
8. Delete the disposable copy (directory, database, and any staging DNS) when you are done

[!CAUTION] The staging copy must use its own database and storage. Reusing the production .env without changing DB_DATABASE will point the staging copy at your live data.

If you cannot create a staging copy, use a fresh local install with demo data to verify the restore workflow. Never test restore on a production installation that contains real business data.

Scheduled backups

Set up automatic backups on a recurring schedule:

1. In the Scheduled Backups section, choose a schedule:
   • Disabled: no automatic backups
   • Daily: creates a backup every day at 02:00
   • Weekly: creates a backup every Sunday at 02:00
2. Set the retention count (how many backups to keep). When a new backup is created, older backups beyond this limit are deleted automatically.
3. Click Save Settings.

The default retention is 5 backups. Set this higher if you need a longer backup history.

CLI commands

Two artisan commands are available for scripting and cron jobs:

Create a backup

php artisan backup:create

Options:

• --passphrase=secret: encrypt the backup with a passphrase

This command also applies the retention policy after creating the backup.

Clean old backups

php artisan backup:clean

Options:

• --keep=N: override the retention count from settings

Encryption

Backups can be encrypted with a passphrase using AES-256 encryption inside the ZIP file. If you use encryption:

• Store the passphrase securely. Without it, the backup cannot be restored.
• Encrypted backups require the passphrase during restore.
• Scheduled backups do not use encryption by default. Use the CLI command with --passphrase for encrypted scheduled backups.

Shared-hosting permissions

The storage/backups/ directory must be writable by the web server. On most shared hosts, permissions of 755 or 775 work. Some hosts require changing the file owner through the hosting control panel.

If backups fail with a permission error, verify the permissions on storage/backups/ and its parent storage/ directory.

Worked example

Acme Corp runs a weekly backup schedule with a retention of 4. After a month, the backup list shows:

When the next scheduled backup runs on 25 May, it creates a new backup and deletes the oldest (27 Apr) to maintain the retention limit of 4.

If Acme needs to restore to the 11 May state, the admin opens Settings > Backups, selects backup_2026-05-11_020000.zip, enters their email to confirm, and clicks Restore. The system creates a safety backup of the current state, restores the 11 May data, and brings the app back online. The admin is redirected to the sign-in page and logs in to verify the restored data.