Backups

What this page is for: set an automatic backup schedule, keep a copy of your data somewhere that is not this server, and put a backup back when you need it.

You need

• The panel open, on the Backups page (in the Panel menu group).
• For storage that is not this server: an AllsWeb Storage bucket (this panel connected to your AllsWeb account), the details of an S3 bucket, another server you can reach over SSH, or a Google Drive account.
• A safe place to keep one password. Not on this server.

The two rules

1. Keep at least one copy of your backups somewhere that is not this server. A local backup dies with the server it sits on.
2. Keep your own copy of the backup password. Every backup is encrypted with it. Without it, nobody can open them — not you, not us.

And one habit: let the panel prove the backup restores. "The backup ran" and "the backup can be opened" are two different claims, and only the second one is worth anything on the day you need it. See section 5.

The panel keeps reminding you about all three. A backup that only lives on this server carries a standing warning, and the panel keeps asking until you tell it you have stored the password off the server. Those warnings are not noise — they are the two ways people lose everything.

1. Choose where backups are kept

1. Open Backups.
2. In the Backup storage (targets) card, press Add backup storage.
3. Pick one:

• This server (local folder) — quickest, and a good first layer. On its own it is not a backup.
• AllsWeb Storage — a bucket you buy on allsweb.com. You pick it from a list; there are no keys to copy. The panel must be connected to your AllsWeb account. Full steps are below.
• S3 cloud storage — Amazon S3, Backblaze B2, Wasabi, Cloudflare R2. You need the endpoint, the bucket name, an access key and a secret key. Full steps are below.
• Another server (SFTP) — any server you can reach over SSH with a private key. The host may be pasted whole (sftp://backup@host:2222): the panel keeps the host and fills an empty user and port from it.
• Google Drive — you paste an rclone configuration once. Read the Google Drive part below before you pick this one.

4. Give it a name you will recognise and save it.

You can add more than one. Adding a second, off-server target is the single best thing you can do on this page.

New storage joins the automatic backups by itself. If automatic backups are on, the storage you just added is one of the places they go from now on, and the wizard's last step says so — for example Nightly backups now go to: This server (local disk) + Backblaze offsite. If they are off, that step offers Turn on daily backups instead. The storage table's Automatic backups column shows, per storage, whether it is included.

Removing a storage takes it out of the automatic backups. If it was the last one they went to, they carry on with every storage that is left — and with none left at all, the top of the page says Automatic backups have nowhere to go until you add one, which then joins by itself.

A worked example: S3 storage at Backblaze B2

S3 sounds harder than it is. Every S3 provider hands you the same four values, and the panel asks for those four and a name you choose. Backblaze B2 is the usual pick here, because it is cheap and it has a free tier.

On the Backblaze website

Backblaze moves its menus around from time to time. Four things are what matter, whatever they are called on the day: the endpoint, the bucket, the key id and the application key.

1. Create an account, then open Buckets under B2 Cloud Storage.
2. Press Create a Bucket. Give it a name nobody else has used, for example myshop-6ammart-backups. Keep the files Private.
3. The new bucket is listed with an Endpoint beside it. It looks like s3.us-west-004.backblazeb2.com. Copy it. Your region number will differ.
4. Open Application Keys → Add a New Application Key. Name it sixpanel, limit it to the bucket you just made, and give it Read and Write access.
5. Backblaze prints a keyID and an applicationKey. The applicationKey is shown one time only. Copy both now, into a password manager.

In the panel

Backups → Add backup storage → S3 cloud storage. Fill the form like this:

Press save. If this is your first backup storage, the panel now shows your backup password — read the next section before you close that box. Then run the first backup. That first run builds the encrypted repository inside the bucket, so it takes longer than every run after it.

Amazon S3, Wasabi and Cloudflare R2 use the same five boxes. Only the endpoint and the names of their own buttons are different.

AllsWeb Storage: a bucket from allsweb.com

AllsWeb sells storage buckets for backups. The panel keeps no key for them: it remembers which bucket you picked, and nothing else.

What you need

• This panel connected to your AllsWeb account: Settings → AllsWeb account.
• A bucket. Get storage in the panel takes you to allsweb.com to buy one, and your buckets are listed on allsweb.com under Dashboard → Storage.

Pick the bucket

1. Backups → Add backup storage → AllsWeb Storage.
2. The panel lists the buckets on your AllsWeb account. Each one shows how much it holds against its quota, and its state: active, suspended, waiting for payment, being created. A bucket this panel already backs up to says already used here. Pick one.
3. Press Test. The panel asks AllsWeb for read-only access and reads the bucket:

• It works — the bucket answers and holds no backup yet: normal for a new bucket. The first backup creates what it needs.
• It works — backups in this bucket: 3: it already holds backups made with this server's backup password.
• …locked with a different backup password: the backups in it were made by another server. Pick another bucket, or give this server that password first (section 2).

4. Keep the name it suggests or type your own, and save. Then run the first backup.

Use one bucket per server. The panel keeps its backups at the top of the bucket, locked with this server's backup password.

If the panel is not connected yet, the form says so and offers Open Settings, which opens the AllsWeb account tab. If your account has no bucket yet, it offers Get storage. The option is always there.

Short-lived credentials, fetched for every run

Every run that touches the bucket — a backup, a restore, the list of backups, the restore test, the clean-up of old backups — first asks AllsWeb for fresh credentials. They work for that one bucket only and expire after a few hours (six by default, never longer than AllsWeb allows). The panel uses them for that run and drops them. They are never written to the panel's settings, the activity log or a job log. Disconnect the account and the panel gets no new ones; delete the bucket and its access ends for good.

When a run is refused, it says why

A suspended or over-quota bucket never blocks a restore. Billing pauses the backups, never your way back: restores and the list of backups keep working.

An unpaid invoice never stops maintenance

Some backups are started by the panel itself, before it changes something: the weekly maintenance window, the safety backup before a project moves to another server, and the backup Tia takes before she updates a shop. When the destination the panel picks for one of those is an AllsWeb Storage bucket that is refused for a billing reason above — suspended, over quota, not active, gone from your account, or the panel no longer connected — the panel takes that backup on your next destination instead, usually this server's own disk, carries on, and emails you exactly what happened:

AllsWeb Storage bucket "Shop backups" is suspended (unpaid) — this window's backup went to the local disk instead; pay the invoice to resume off-server backups

So that week's security updates still go in. Once the bucket is usable again, the next one goes back to it by itself. If allsweb.com cannot be reached, or the backup itself fails, the window stops as it always has. A backup to a bucket you chose — Run backup now, or the schedule — is never sent anywhere else: it fails and says why.

Google Drive: what it really takes

The panel does not log in to Google for you. It reads a configuration file made by a separate free program called rclone, and the remote inside that file must be named exactly gdrive6am.

If you have never used rclone, choose S3 above instead. It is fewer steps and nothing has to be installed on your own computer.

If you want Drive anyway, on your own computer (not the server):

1. Install rclone from rclone.org.
2. Run rclone config, choose n for a new remote, and name it exactly gdrive6am. Any other name is refused by the panel.
3. Choose drive as the type. Leave the client id and client secret empty. Accept the default answers, and let it open a browser so you can sign in to Google.
4. Run rclone config file. It prints the path of rclone.conf. Open that file and copy the whole [gdrive6am] block.
5. In the panel, pick Google Drive, leave the folder path as it is, and paste that block into the configuration box.

Each Google Drive storage keeps its own sign-in, so you can add a second one for another Google account — give it a different folder path — without disturbing the first. If you leave the folder another Drive storage already uses, nothing is saved yet: the panel names that storage and asks which you meant — Choose another folder for the new account, or Replace the sign-in of the storage that has the folder (for when its sign-in stopped working). Removing a Drive storage deletes its sign-in from this server.

2. Save the backup password

Every backup on this server is encrypted with one password. The panel generated it, the panel uses it automatically for every backup and restore, and you never type it. You need your own copy for exactly one situation: this server is gone, and you are restoring its backups onto a new one.

The Backup password card holds everything about it.

Show the backup password displays it. You can do this whenever you like — it is your key, on your server. Each time you look, the panel writes a line in the activity log saying the password was displayed, so a look is never silent.

Save it. Copy that password into a password manager, or write it on paper you keep somewhere else. If this server is lost and you do not have the password, the backups can never be opened by anyone. There is no way to reset it — the only thing you can do is change it, and that needs the current one to still work (see below).

"I have a copy — stop reminding me" turns off the reminder. Press it only when the password really is written down somewhere that is not this server. The panel records the date and stops nagging, on this page and on the Health page.

Changed your mind, or moved to a new password manager and want the reminder back until you are sure? Remind me again switches it back on. Nothing else changes.

Over SSH, as root:

Do not run this while you are sharing your screen or recording a call. It prints the password in plain text, right in your terminal. Clear the terminal afterwards, and close that window rather than leaving the password in its scrollback.

sudo sixpanel backup password

The command asks you to confirm before it prints anything.

Change the backup password

Change the password on the same card issues a new one and re-keys every backup storage in place. Every backup you already have stays readable with the new password, and nothing is uploaded again.

It runs as a job with four named steps, and you watch each one:

1. Check every backup storage is reachable. All of them must answer before anything changes. If one is unreachable the job stops here and nothing has been touched. That includes a storage you added and never used: fix it, or remove it from the page, and try again. A storage that answers and simply holds no backup yet is fine — there is nothing in it to change. A storage you have backed up to, whose backups cannot be found at this moment (a disk that is not mounted, a folder that was moved), also stops the job: changing the password without it would leave those backups on the old one. Reconnect it; or, if they are really gone, run a new backup to it or remove it.
2. Add the new password to every repository. If one storage refuses half way through, the panel removes the keys it already added and stops — so no storage is left wanting a different password from the others.
3. Switch this server to the new password. From this moment the panel backs up and restores with the new one.
4. Remove the old password from every repository. The old password stops working.

Afterwards the reminder turns itself back on, because the copy you saved is now the wrong one. Press Show the backup password, save the new value, and then press I have a copy again.

Use this if the old password was seen by someone it should not have been, or when you hand a server over to somebody else.

3. Pick a schedule

If nothing is set up yet, the top of the page says Automatic backups are OFF and offers Enable daily backups — one press and you are protected, with encrypted storage created on this server and old backups tidied for you.

For more control, use the Automatic backups card and press one of the plans:

• Daily (recommended) — every night at 03:30. Keeps 7 daily, 4 weekly and 3 monthly backups.
• Twice a day — 03:30 and 15:30, for busy projects.
• Weekly — every Sunday at 04:00. Keeps the last 8 weekly backups.
• Custom — your own time and your own retention numbers.

If you have no backup storage yet, saving a plan creates encrypted storage on this server by itself — and that is when the password card appears.

A plan you pick covers every storage you have, and Stored in under the plans names them, joined by +. Storage added later joins the plan by itself (section 1).

Old backups are removed for you, following the retention numbers of the plan.

Staging sites are left out of the scheduled backups. A staging site is disposable — Refresh from production rebuilds it — so the plan skips it unless you include it. The Automatic backups card lists every copy with an Include in scheduled backups switch, and a backup you run yourself (section 4) still takes them all (Staging & Testing → Backups).

4. Run one now

Use the Run a backup now card. Choose What to back up:

• Everything (database + files)
• Database only
• Files only (uploads + settings)

Press Run backup now and watch the log.

Over SSH, the same thing:

sudo sixpanel backup run full

Backups after the first one are small: only what changed is stored.

5. Prove the backup can be restored

The Can your backup be restored? card answers the only question that matters on a bad day.

It takes your newest backup and proves every database in it — each project's, and each website's — not just one. For each one it restores that dump out of the backup, loads it into a throwaway database with a name of its own, counts the tables and the rows, and deletes the throwaway database again before starting the next. The shops go first.

If you run more than one shop on this server, the result names each of them separately, so "the backup is fine" is a statement you can act on rather than one you have to trust. A project the backup does not cover — one you created after the last backup ran, for instance — is listed by name as not in this backup rather than quietly counted as a pass.

Websites are named as websites in the same line. A WordPress site must bring back its options and its users, with rows in both, or the test fails for it by name. Any other website's database is checked for its tables; one with no tables yet — an app that has not created any — is nothing to prove, not a failure. A website made after the last backup is listed as not in this backup, like a project. And a website dump that picks a database of its own is not loaded at all — loading it could write into a live database — so it is listed as not tested, with the reason.

Your live site and your live database are never touched by this. The test only ever creates and deletes a database it made itself, and it refuses to touch any other name.

Run it once now: press Test my backup now, confirm, and watch the log. On a big project it takes a few minutes and uses some disk space while it runs.

Then leave it on: Test my backup every week, by itself runs the same test every Sunday morning. Leave this on. It costs you nothing and it is the only thing that tells you the truth before you need it.

What the result means

Server → Health reports the same result, and warns as soon as the test is overdue for its own schedule — a weekly test that missed one Sunday is already worth telling you about.

When the test fails

A failed test is a real emergency, and it is much better to meet it today than on the day the server dies. In order:

1. Read the job log. It lists every table it found and the row counts, so the line that says MISSING or 0 rows names the problem.
2. Run a fresh full backup: Run a backup now → Everything (database + files).
3. Run Test my backup now again.
4. If it fails a second time, do not wait. Take a database copy you can hold in your hand — Database → download a copy — and send support the file from sudo sixpanel support-bundle.

A common and harmless-looking cause: the schedule is set to Database only or Files only, so no snapshot holds a full database. Set it to Everything and run it again.

6. What is inside a backup

• The database of every project on this server (a scheduled backup leaves out the staging sites you have not included — section 3).
• Uploaded files (product images, logos, documents) and each project's settings file.
• Every website — static, Node.js, PHP, WordPress and Create with AI: its database and its files (Websites → Backups).

Your 6amMart application code is not inside the backup. Code comes back from your git repository or from your CodeCanyon zip. A backup holds your data and your settings. A website's code is inside, because for most websites nothing else holds it.

A website comes back from its own Backups page, or from this page's Restore: the dialog lists the websites a backup holds beside the projects (the Contents column says how many), and only the one you pick changes. Over SSH: sudo sixpanel backup restore <SNAPSHOT> --site NAME.

7. Restore a backup

This cannot be undone. A restore writes the backup over your live data. Anything created after that backup was taken is lost — and that includes database tables an update has added since: they are removed once the backup has loaded, so the next update can make them again. Take a fresh backup first if the current data still has any value.

In the panel:

1. Backups → the Snapshots & restore card. It opens on the storage that holds your newest backup; with more than one storage, pick another from the menu to see its backups.
2. Find the one you want and press Restore this snapshot.
3. Choose which project or website to put back, and what to put back, then confirm. Only the one you pick is touched.

Stored times and the database's time zone. A backup comes back exactly as it was on a database that runs on the same time zone as the one it was taken on. If you have changed this server's database zone since (Server → Database), or you restore on another server whose database runs on a different zone — a server newly set up with SixPanel runs its database on UTC, one set up before 1.5.2 may follow your local time — every row is there, but its stored times are read through the other zone and are off by the difference. The restore's log says so when it can tell, and Database server says how to put such a backup back with its times unchanged.

Over SSH:

sudo sixpanel backup list
sudo sixpanel backup restore SNAPSHOT_ID

SNAPSHOT_ID is an id from the list. The word latest also works. Add --what db to put back only the database, or --what files for only the files. Without it, both are replaced.

With more than one project on the server, say which one to restore into — the command names that project before it asks you to confirm:

sudo sixpanel --project SLUG backup restore SNAPSHOT_ID

sudo sixpanel project list shows each project's slug.

After a restore, restart the site:

sudo sixpanel service restart app

How to check it worked

• The top of the Backups page shows the last backup and when the next one runs.
• The Backup status card shows, for each storage, when its newest backup was taken, how many it keeps and how much the newest one restores.
• The Backup storage table shows each storage as included under Automatic backups, and at least one of them is not this server.
• The Backup password card says you confirmed a copy exists outside this server, with the date.
• Can your backup be restored? says Passed, with a date and a table count, and the weekly test is on.
• sudo sixpanel backup list prints at least one snapshot with a date.
• sudo sixpanel backup targets prints each destination and its last run.

If it went wrong

• "repository is already locked" — an earlier run stopped in the middle. Wait one minute and run the backup again. If it keeps saying this, send support the file made by sudo sixpanel support-bundle.
• The backup fails on S3 or SFTP — the keys, the bucket name or the SSH key are usually the cause. Remove the storage and add it again with fresh details. The job log names the step that failed.
• An SFTP backup fails with "host key verification failed" — the backup server was rebuilt or replaced since you added it, and the panel refuses a server whose identity changed. If that was you, remove the storage and add it again: removing it forgets the old identity. If it was not you, do not — find out what is answering at that address first.
• The password change stopped at "Check every backup storage is reachable" — one of your destinations did not answer. Nothing was changed. Fix that destination (or remove it if you no longer use it) and run the change again.
• The restore test failed — see When the test fails in section 5. Until it passes, treat your backups as unusable.
• The restore test says it could not run — the usual reason is disk space. A compressed database dump needs roughly twelve times its own size to load. Free space on Server → Resources and test again.
• A storage says "not included" under Automatic backups — it was added before new storage joined the plan by itself, or taken out of a custom plan. Press Include beside it: the plan keeps its time and how long it keeps backups, and adds that storage.
• "Automatic backups have nowhere to go" — every storage the plan used was removed. Add backup storage; it joins the plan by itself.

Still stuck? Run sudo sixpanel support-bundle and send us the one file it writes. See When something is broken.