Backup Add-on Guide for Larapen

30 min read Last updated Oct 07, 2026 48 views

Take a complete, verifiable copy of your site, database and files, on a schedule, send it somewhere that is not the server it came from, and put it back with one guarded screen. Restoring an archive on a different installation is also how you move your site to a new server.

Works on Any Host

Uses mysqldump where the server allows it, and falls back to a built-in PHP dumper where exec() is disabled, which is most shared hosting.

Off-Site by Design

Local disk, S3-compatible storage, FTP, SFTP and Dropbox, each with a one-click connection test.

Scheduled and Pruned

Daily, weekly, monthly or a cron expression of your own, with a retention policy that removes old archives for you.

Guarded Restore

A dry run first, an automatic safety backup, maintenance mode, a URL rewrite, and a confirmation that asks for your password.

Use Cases

Nightly insurance

The case everybody needs and nobody sets up in time.

A full backup every night at 03:00, sent to storage outside your server.
The last seven kept, anything older than thirty days removed automatically.
An email the moment a run fails, so you find out before you need the archive.

Before you change something risky

An update, a new add-on, a theme you are not sure about.

Run a full backup by hand from the admin panel, wait for the green badge, then proceed.
If the change goes wrong, restore that archive and you are back where you started.

Moving to a new server

A migration is a backup on one machine and a restore on another.

Take a full backup on the old site and download it.
Install the CMS on the new server, activate this add-on, upload the archive and restore it.
The URL rewrite step replaces the old address everywhere it appears in the database.

Keeping a copy you can hand over

An archive is a single file: a client handover, an audit copy, a local development snapshot.

Encrypt it with a password before it leaves the server.
Split it into volumes when the receiving side has a file-size limit.

Requirements

Larapen CMS v1.0.0 or later
PHP 8.3+ with the zip and openssl extensions
MySQL 8.0+
A working queue worker: backups and restores never run inside a web request
A cron entry for the scheduler, if you want scheduled backups (see The Cron Entry)
Nothing extra for the off-site destinations: the S3, FTP, SFTP and Dropbox libraries ship with the application

exec() is not required. If your host disables it, or mysqldump is not installed, the add-on switches to its own PHP dumper automatically. You do not have to configure anything: the Health Check page simply reports which one is in use.

Installation

Step 1: Upload the Add-on

In the admin panel, go to Admin → Extensions → Add-ons and click the Upload Add-on button. Select the add-on’s ZIP file: the system extracts it automatically and the add-on appears in the installed add-ons list.

Step 2: Activate the Add-on

Find Backup & Restore in the list and click Activate. Its tables and permissions are created automatically, along with a ready-to-use Local storage destination: archives land in the private storage folder, outside the web root. Nothing runs on its own until you create a schedule and set up the cron entry.

Step 3: Check the Server

Open Admin → Backup → Health Check and read the report before you rely on anything. See Health Check.

Purchase Code (License Key)

Backup & Restore is sold as a separate product, so it has its own purchase code (license key), distinct from the purchase code of the main application and from the one of every other add-on. You are asked for it when you activate Backup & Restore in Admin panel → Add-ons.

Our products are sold on three platforms. The way you receive a purchase code depends on where you bought the product.

Platform / Marketplace	How you get the purchase code	Where to find it again
bedigit.com Store In-site purchase (Shop)	Generated automatically when the order is paid, then sent by email, either in its own license email, or inside the order confirmation email.	My Account → My Licenses on bedigit.com
Gumroad	Created as soon as Gumroad notifies us of the sale, then sent in a separate email, in addition to the Gumroad receipt.	The license email, your Gumroad Library, and My Account → My Licenses on bedigit.com
Envato Market CodeCanyon	Issued by Envato, not by us, and never sent by email: you download it yourself from your Envato account.	Envato account → Downloads → License certificate & purchase code

Check your spam folder. For both bedigit.com Store and Gumroad purchases, the purchase code is delivered by email. Automated license emails are very often filtered, so if the message is not in your inbox, look in your spam / junk folder before contacting support, and add our sender address to your contacts or allow list.

1. bedigit.com Store (in-site purchase)

As soon as the order’s payment status becomes Paid, a license key is generated automatically for every licensed item in the order (one key per purchased unit: buying 3 units gives 3 distinct keys).
It is emailed to the address used on the order, either in a dedicated license email or inside the order confirmation email. Check your inbox and your spam / junk folder.
The key stays available in your account under My Account → My Licenses. Keys are masked in the list; open the license detail page to reveal and copy the full key, see the domains it is activated on, and deactivate a domain to free an activation slot.
The matching invoice is under My Account → My Orders.

2. Gumroad

A Gumroad purchase produces two separate emails: the Gumroad receipt (sent by Gumroad, giving access to the files) and a license key email (sent by bedigit.com) that contains your purchase code.
The license key email is generated as soon as Gumroad notifies us of the sale, so it normally arrives within seconds of the payment. Here too, check your inbox and your spam / junk folder.
When the Gumroad product uses Gumroad’s own license-key feature, the same key also appears in your Gumroad receipt and under Library in your Gumroad account.
The key is recorded on your bedigit.com account as well, under My Account → My Licenses.

3. Envato Market (CodeCanyon)

Envato issues the purchase code itself. We never send it by email, because we do not receive it.
Get it from your Envato account: Downloads → find the item → License certificate & purchase code (the text or PDF version both contain it).
It looks like xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

Still cannot find it? Open a ticket from our Help Center with the email address used for the purchase and, where applicable, the order number or the Gumroad receipt. We can look the key up for you.

Quick Start

Getting a first archive on disk takes about a minute.

Go to Admin → Backup → Health Check and make sure nothing is flagged red.
Go to Admin → Backup → Backups and click Run a backup.
Leave the type on Full, pick the Local storage destination and click Start backup.
The row appears immediately with a progress bar. You can leave the page: the run is on the queue.
When the badge turns green, click the row to see the step log and what went into the archive.

A backup on the same server is not a backup. It survives a bad update; it does not survive a dead disk, a compromised account or a lost hosting plan. Add a second destination that is somewhere else, see Destinations, and point your schedule at it.

Health Check

Admin → Backup → Health Check answers, in advance, the questions you would otherwise only discover at three in the morning.

Check	What it means
Free disk space	A backup needs room for the archive and for the database dump while it is being built. Red means there is not enough.
PHP zip extension	Required. Without it no archive can be created at all. Ask your host to enable it.
mysqldump	Green when the binary is reachable. Amber is normal and harmless: the built-in PHP dumper is used instead.
Maximum execution time	Queue workers usually ignore this, but a very low limit can cut a long run short.
Memory limit	Backups stream rather than load files into memory, so a modest limit is normally fine.
Writable working folder	Where archives are staged while they are built. Red means a permissions problem to fix.
Archive location	Red if any destination stores archives inside the public folder, where anyone could download them. Fix this immediately.
Queue connection	Amber when the queue is set to `sync`, which would run the backup inside the request that started it.

The same page lists every destination type and confirms that the library behind each one is present, with the command that restores it should any be missing.

Backup Types

Type	Contains	Use it when
Full	The database and the files.	Always, for your scheduled backups. It is the only type you can migrate from.
Database only	A single SQL dump.	Frequent, cheap snapshots between full runs: your content changes far more often than your files.
Files only	The selected folders and files.	Before replacing a theme or a large media library, when the database is not involved.

What Is Included

The default selection covers everything a working installation needs: the application code, your configuration, your themes and add-ons, your language files and your uploaded media. You can change it under Admin → Backup → Settings → What to back up, or per schedule.

Two heavy items are toggles rather than plain entries:

The vendor folder is excluded by default. It is large and re-creatable with a single Composer command, so leaving it out often halves the archive. Include it if the target server has no Composer access.
Uploaded media is included by default. Turning it off makes the archive dramatically smaller and dramatically less useful, only do it if your media is already backed up elsewhere.

Some things are always skipped, whatever you configure, because including them would be wrong rather than merely wasteful: compiled caches, session and view files, logs, .git, node_modules, and the backup folders themselves: an archive must never contain itself.

Symbolic links are followed, safely. Themes and add-ons are often links to folders elsewhere on the server, so the archive follows them and stores the real files. A link whose target no longer exists is skipped and recorded in the log rather than stopping the run, and a link that points back at its own parent is not followed twice.

How the Dump Works

The database is exported one of two ways, chosen automatically:

mysqldump, when the server allows PHP to start a process and the binary is installed. It is faster on large databases and produces the format every MySQL administrator already knows. Your database password is passed in a temporary credentials file, never on the command line where other users of the server could read it.
The built-in PHP dumper otherwise. It reads the tables through the ordinary database connection in small batches, so memory use stays flat no matter how large a table is. This is the path most shared hosting takes, and it needs nothing from your host.

You can force either one under Settings → Engine → Database dump method, but the automatic choice is almost always right.

Running a Backup

Click Run a backup on Admin → Backup → Backups. You choose:

an optional name, to find the archive again later;
the type (see above);
the destination it is sent to;
whether to encrypt it, and with what password.

The run is queued, not executed in your browser, so a large site cannot time out. The row shows a live progress bar and the current step; you can close the page and come back.

Every finished backup can be downloaded, restored or deleted from its row. Deleting a backup deletes the archive behind it, wherever it is stored.

Encryption

An archive holds your database: user accounts, password hashes, orders, private uploads. If it is going to leave your server, encrypt it.

Encryption is AES-256 with a key derived from your password, applied to the finished archive as it streams to disk, and sealed with an integrity check so a damaged or tampered file is rejected before anything is restored from it.

The password is never stored. Only a hash of it is kept, so the restore screen can tell you straight away that you typed the wrong one. If you lose the password, the archive cannot be opened, not by you, and not by us. Keep it in your password manager.

A schedule runs unattended and cannot ask anyone for a password, so an encrypted schedule stores one, encrypted, alongside it. Keep your own copy of that password too.

Splitting Large Archives

Under Settings → Engine → Split archives over you can set a volume size in megabytes. Archives larger than that are cut into numbered parts (.001, .002 and so on), which is what some hosts and some destinations require.

Split archives are recombined automatically when you restore them, so you never have to join them by hand. If you do want to do it yourself, the parts are plain byte ranges and cat archive.zip.* > archive.zip rebuilds the original.

A split archive cannot be downloaded from the admin panel as a single file; fetch the parts from the destination directly, or restore it from where it is.

Destinations

A destination is where finished archives are sent. Add and edit them under Admin → Backup → Destinations; each opens in a dialog on that page. Every destination has a Test connection button that writes a small file, reads it back and deletes it, so “it works” means it really works, not just that the credentials look plausible.

One destination is the default: it is pre-selected whenever you run a backup. Keep more than one, and point your schedule at an off-site one.

This Server

Archives are kept on the same machine, in the private storage folder, which is outside the web root on a standard installation. You can point it at any absolute path (a sibling of the web root, a mounted volume), but not at a folder inside public/: that is refused, because an archive reachable over the web is a complete copy of your site handed to anyone who guesses the filename.

S3-Compatible Storage

One destination type covers Amazon S3 and every service that speaks the same protocol.

Amazon S3: fill in the access key, secret, region and bucket, and leave the endpoint blank.
Wasabi, Backblaze B2, DigitalOcean Spaces, MinIO and others: fill in the same fields, set the endpoint your provider gives you, and switch path-style addressing on.

Use a key that can only write to the backup bucket. A key with wider access turns a compromised site into a compromised storage account.

FTP and SFTP

FTP asks for a host, credentials, a port and a folder, with optional passive mode and FTPS. SFTP is the same over SSH and accepts either a password or a private key: paste the key itself, not a path to it, and leave the password blank when you use one.

Prefer SFTP. Plain FTP sends your credentials and your entire archive unencrypted.

Dropbox

Dropbox connects to an account rather than taking a password, which takes three steps:

Create an app in the Dropbox App Console and copy its key and secret.
Click Add a destination, pick the type, paste the key and secret, and save. The form shows a Redirect URI: copy it into the list of allowed redirect URIs in your app.
Click Connect account, approve the request at Dropbox, and you are returned to the destination with the account connected.

Only a long-lived refresh token is kept; the short-lived access token is renewed automatically before each transfer, so a long backup cannot expire halfway through. Disconnect removes both.

Storage Libraries

Every destination type listed above works out of the box: the libraries behind them (for S3, FTP, SFTP and Dropbox) ship with the application, so there is nothing to install and nothing to configure before you can add a destination.

You may still see a type reported as Unavailable if its library has gone missing from the server: most often because a partial upload replaced vendor/, or because a deploy skipped the dependency step. That is not a crash: the type is greyed out with the exact command that restores it, and a backup aimed at it fails with that message rather than a blank error. The commands appear on the Health Check page and on the Destinations page; run the one shown from your installation folder and reload.

Nothing to install. If a type is greyed out, treat it as a sign that the installation is incomplete rather than as a missing optional extra: the rest of the application depends on the same vendor/ folder.

Schedules

A backup you have to remember to run is a backup you will not have. Create a schedule under Admin → Backup → Schedules.

Each schedule has its own type, destination, file selection, encryption and retention, so you can run a nightly database snapshot to one place and a weekly full backup to another.

Frequency	You choose
Every day	The time of day.
Every week	The day of the week and the time.
Every month	The day of the month (up to 28, so it fires in February too) and the time.
Custom	A five-field cron expression, validated as you save it.

The list shows the resolved cron expression and the next run for every schedule, so you can see at a glance whether one is actually going to fire. Run now queues a schedule immediately without waiting for its time.

The Cron Entry

Schedules are data, not code: something has to wake the application up and ask which ones are due. That is the scheduler, and it needs one cron entry on the server. Without it, no schedule ever runs: this is by far the most common reason scheduled backups silently do not happen.

The exact line for your installation, with your own paths already filled in, is shown at the top of the Schedules page with a copy button. It looks like this:

* * * * * /usr/bin/php /path/to/your/site/artisan schedule:run >> /dev/null 2>&1

Add it to the crontab of the user that owns the site:

crontab -e

If your host gives you a cron panel rather than a shell, create a task that runs every minute with the same command. Every minute is correct and costs nothing: the scheduler exits immediately when nothing is due, which is how a schedule set to 03:17 fires at 03:17.

Check it took effect. After adding the entry, enable a schedule and use Run now to confirm backups work at all, then look at the Next run column the following day: if it has not moved, the cron entry is not running.

Retention

Without a retention policy, archives accumulate until the disk fills, which typically breaks the site and the backups at the same moment. Each schedule has two limits, and you can use either or both:

Keep the last N backups: the newest N from that schedule survive.
Keep for X days: anything older is removed.

Set a value to 0 to switch that half of the rule off. Setting both to 0 keeps everything forever.

Pruning removes the archive as well as the entry, and runs after each scheduled backup and once a day. Backups taken automatically before a restore are never pruned: they exist precisely for the case where everything else went wrong.

Console Commands

Everything in the admin panel is also available from the command line, which is what you want in a deploy script or when the site itself will not load.

php artisan backup:run --type=full
php artisan backup:run --type=database --sync
php artisan backup:run --destination="Off-site S3" --password="your passphrase"
php artisan backup:schedule
php artisan backup:prune --dry-run

Command	What it does
`backup:run`	Queues a backup. `--sync` runs it in the foreground instead, which is what a deploy script wants. `--type` takes `full`, `database` or `files`.
`backup:schedule`	Queues every schedule that is due. Called automatically by the scheduler each minute.
`backup:prune`	Applies every retention policy and trims the activity log. `--dry-run` reports without removing.

Restoring a Backup

Restoring overwrites the database and the files of this installation. It is the one irreversible action in the add-on, so it is deliberately a three-step process rather than a button.

Go to Admin → Backup → Restore. You can restore from an archive this installation produced, or from one you upload: the second is how you move a site between servers.

Step 1: The Dry Run

Choose an archive (or upload one), give its password if it is encrypted, and click Inspect archive. Nothing is changed: the archive is fetched, decrypted, opened and described.

The report tells you:

whether it contains a database dump, files, or both, and how many of each;
a sample of the entries inside it;
an environment comparison: the site URL, PHP version, database driver, table prefix and application version the archive came from, each against this installation.

Differences are not errors: they are what a move between servers looks like. Read them before you continue. A different table prefix or database driver is the one combination worth stopping for: the archive will recreate its own tables, and the installation’s configuration must match them afterwards.

Step 2: The Options

Option	What it does
Restore the database	Replays the SQL dump. Available only if the archive holds one.
Restore the files	Writes the archived files over the installation. Available only if the archive holds any.
Drop existing tables first	Recommended. Without it, tables this installation has and the archive does not would survive the restore, leaving a state neither side ever ran.
Take a safety backup first	Leave this on. A full backup of the current state, taken before anything is overwritten.
Maintenance mode	Visitors see a maintenance page while the restore runs. The site is brought back up afterwards even if the restore fails.
URL rewrite	Replaces one string with another everywhere in the database. Pre-filled with the old and new site addresses when they differ.

The URL rewrite is what makes a migration actually work. The old address is baked into page content, menu links, stored settings and cached payloads, and it is handled correctly even inside serialised values, where a naive find-and-replace would corrupt the data.

Step 3: The Confirmation

To start the restore you must:

hold the dedicated Run a restore permission;
give the archive password, if it is encrypted;
type your own account password;
type the word RESTORE exactly;
confirm the prompt that follows.

The account password is what stops an unattended admin session from being turned into a wiped site by whoever walks past the keyboard.

What Happens While It Runs

The archive is fetched from its destination, recombined if it was split, and decrypted.
A full safety backup of the current state is taken and finished before anything else starts.
The site goes into maintenance mode.
The database is dropped and replayed from the dump, in batches.
The files are written over the installation. Entries that try to escape the installation folder are refused.
The URL rewrite runs over the restored database.
The site is brought back up, and everyone with the notification enabled is emailed.

Every step is recorded in the log on the restore’s own page, with timings, so you can see exactly what happened and where it stopped if it did.

Moving to a New Server

There is no separate migration feature, because there does not need to be one: restoring an archive on a different installation is the migration.

On the old site, run a Full backup and wait for it to finish.
Download the archive. If it is split into volumes, fetch every part.
On the new server, install the CMS normally and point it at an empty database.
Activate Backup & Restore on the new installation.
Go to Restore, upload the archive, and click Upload and inspect.
Read the environment comparison. The site URL will differ: that is the point.
Check that the URL rewrite is pre-filled with the old address and the new one, correct it if needed, and confirm the restore.
When it finishes, log in on the new site and check a few pages, the media library and a form.

Upload limits. Archives are often larger than a PHP upload allows. If the upload is refused, either raise upload_max_filesize and post_max_size on the new server, or, simpler, put the archive on a destination both servers can reach (S3, SFTP, Dropbox), add that destination on the new installation, and restore it from there instead of uploading it.

Keep the old site until you are sure. Do not change DNS, and do not delete anything, until you have clicked through the new site properly. A migration you can still back out of is not really a risk.

If a Restore Goes Wrong

The safety backup is the recovery path. It is a normal full backup, listed with the others and marked Safety backup, and it is never removed by a retention policy.

Go to Admin → Backup → Backups and find the entry named Before restore with the timestamp of the attempt: it is also linked from the restore’s own page.
Restore it the same way you restored the other archive.
Use the same archive password you used for the failed restore: the safety copy is encrypted with it too, so it is never less protected than what it replaced.

If the site will not load at all, the same thing is possible from the command line, which does not need the admin panel to work. Should the site be stuck showing a maintenance page after an interrupted run, bring it back with:

php artisan up

Security

An archive is your entire site in one file. The add-on is built around that fact.

Archives are stored outside the web root. The default location is the private storage folder, and a destination pointed inside the public folder is refused outright.
Downloads go through a signed, expiring link. The link is minted when you click, checked against your permissions, and expires after a few minutes, so a URL copied out of a browser history or a shared screenshot is already dead.
Every credential is encrypted at rest. S3 secrets, FTP passwords, SSH keys and OAuth tokens are encrypted in the database, masked in the forms, and never written to a log.
Encrypted archives are sealed. A truncated or tampered archive fails its integrity check before a single byte is restored.
Restores are guarded. A separate permission, a dry run, a typed confirmation phrase and your account password.
Uploaded archives are treated as untrusted. Entries that try to write outside the installation folder are refused and logged.

Encrypt anything that leaves the server. Cloud storage, an FTP account, a copy on your laptop: all of them are places your database can be read from if the archive is not encrypted.

Notifications

Three notifications go to administrators, by email and in the admin bell:

Backup succeeded: name, type, size, destination and duration.
Backup failed: the reason, and a link to the step log. This is the one that matters.
Restore finished: whether it succeeded, and where the safety backup is.

Success emails can be switched off entirely under Settings → Notifications: a nightly schedule that mails every administrator every morning trains everyone to filter exactly the message they need to read. Failures are always sent. Individual administrators can tune their own preferences under Admin → Notifications.

Activity Log

Admin → Backup → Activity Log holds every step of every backup and restore, with timings, filterable by level and by step. Each backup and each restore also shows its own log on its detail page, which is usually where you want to look.

Warnings are worth reading even on a successful run: a skipped unreadable file or a broken symbolic link is recorded there rather than failing the backup. Entries are trimmed automatically after the number of days set in Settings → Retention.

Global Settings

Admin → Backup → Settings holds the defaults every backup starts from.

Tab	Settings
Engine	Database dump method, compression level, and the volume size for splitting.
What to back up	The default include and skip lists, and the vendor and uploaded-media toggles.
Retention & downloads	How long log entries are kept, how long a download link lives, and the largest archive that can be uploaded.
Notifications	Whether successful backups are emailed.

Compression is a trade: 0 stores without compressing, which is fastest and largest; 9 compresses hardest, which is slowest and smallest. 6 is a sensible default and the one to keep unless you have measured a reason not to.

Permissions

The add-on registers its own permissions, assignable per role under Admin → Users → Roles.

Permission	Allows
`backup.backups.view`	See the backups list and the step log.
`backup.backups.create`	Run a backup, and run a schedule now.
`backup.backups.download`	Download an archive.
`backup.backups.delete`	Delete a backup and its archive.
`backup.destinations.view`	See destinations and test their connections.
`backup.destinations.edit`	Add, change and delete destinations.
`backup.schedules.view`	See schedules.
`backup.schedules.edit`	Add, change and delete schedules.
`backup.restore.run`	Inspect and restore an archive.
`backup.logs.view`	See the activity log.
`backup.settings.view`	See the settings and the health check.
`backup.settings.edit`	Change the settings and clear the log.

Grant backup.restore.run sparingly. It is the only permission in the add-on that can destroy data, and it is separate from the rest precisely so a role can be trusted with backups without being trusted with restores.

Multi-Language

Every screen, email and notification ships translated into the same languages as the CMS itself, and follows whichever language the administrator has chosen. Nothing about a backup is visitor-facing, so there is nothing here to translate yourself.

Updating

There are two ways to update this add-on: via the admin panel (recommended) or manually replacing files.

Method 1: Admin Panel Upload (Recommended)

Download the latest .zip file of this add-on.
Go to Admin panel → Add-ons and click the Upload button.
Select or drag the .zip file into the upload area.
A confirmation prompt will show the current and new version numbers. Click Replace to proceed.
Go to Admin panel → System Update (/admin/update) to apply any pending database migrations.

Method 2: Manual File Replacement

Step 1: Replace Files

Replace the add-on directory with the new version.

Step 2: Run Migrations

php artisan migrate

Pending migrations run once, so the command is safe to repeat.

Step 3: Clear Caches

php artisan config:clear
php artisan route:clear
php artisan view:clear

Step 4: Verify

Open Admin → Backup → Health Check, then run one backup by hand to confirm the engine still works end to end.

Take a backup first. You have the tool for it: run a full backup before updating anything, including this add-on.

Deactivating

Switching an add-on off without losing anything is a deactivation: go to Admin panel → Add-ons, find Backup & Restore and click Deactivate.

Its routes, views, admin menu entries and permissions stop being registered.
Schedules stop firing. No backups are taken while the add-on is deactivated: this is the one to think about before you switch it off.
Its database tables and all the data they hold are kept, and the archives themselves are untouched on every destination.
The purchase code recorded at activation is kept too, so activating the add-on again does not ask for it.
Deactivation is refused while another active add-on depends on this one: deactivate that add-on first.

Click Activate on the same card to switch it back on. Pending migrations are re-run and the add-on picks up exactly where it left off, including your destinations and schedules.

Removing

Removing is permanent and destroys the add-on’s data. The Remove button only appears on a deactivated add-on, so removal is always two steps:

Deactivate Backup & Restore (see Deactivating).
Click Remove on its card and confirm the prompt.

The admin panel then, in one pass:

runs the add-on’s uninstall hook, if it ships one, while its code is still on disk;
revokes the permissions declared in its addon.json;
rolls back its migrations, this drops its database tables and every row they hold: your destinations, your schedules, the record of every backup, and the whole activity log, and purges its entries from the migrations table, so a later reinstall migrates from scratch;
deletes its published assets and the add-on directory;
deletes its row in the addons table (the recorded purchase code goes with it) and clears the application cache.

Your archives are not deleted, and they become orphans. The files stay exactly where they are on each destination, but the add-on’s record of them is gone, so nothing lists them any more. Download the archives you want to keep before removing, and note their passwords: an encrypted archive whose password you have lost is unreadable.

Troubleshooting

The backup stays “Queued” and never starts

No queue worker is running. Backups are deliberately never executed inside a web request, so without a worker they wait forever. Start one, or ask your host to keep one running.

Scheduled backups never run

Almost always the missing cron entry: see The Cron Entry. Check the Next run column: if it never moves, the scheduler is not being called. Confirm the schedule is Active, and use Run now to prove backups work independently of the schedule.

The backup fails partway through

Open the backup and read its step log: it names the step and the reason. The usual causes are disk space, a destination that has stopped accepting writes, and credentials that have expired. Test the destination from its own page.

“Unavailable” on a destination type

These libraries ship with the application, so this normally means the installation is incomplete: a partial upload, or a deploy that skipped its dependency step. The exact command that restores it is shown next to it; see Storage Libraries.

The archive is enormous

Uploaded media and the vendor folder dominate the size. Exclude the vendor folder (it is excluded by default), raise the compression level, and consider a nightly database-only backup with a weekly full one.

“Wrong password” on an encrypted archive

The password is checked against a hash before any decryption is attempted, so this message is reliable: it really is not the password the archive was made with. There is no recovery path: that is what encryption means.

The site is stuck on the maintenance page

A restore that was interrupted at the wrong moment. Run php artisan up on the server.

After a migration, links still point at the old domain

The URL rewrite was skipped or had the wrong values. Restore the archive again with the correct Find and Replace with values: use the exact form the old site used, with the protocol and no trailing slash.

Still stuck?

Open a ticket from our Help Center. Include the step log of the failed run and the Health Check page: together they usually contain the answer.