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: 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.
• 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.
• Google Drive — you paste an rclone configuration once. Read the Google Drive part below before you pick this one.

1. 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.

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.

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.

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.
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.

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

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 project's database in it — not just one. For each one it restores that project's 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.

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.

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.
• Uploaded files (product images, logos, documents) and each project's settings file.

Your 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.

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. Take a fresh backup first if the current data still has any value.

In the panel:

1. Backups → the Snapshots & restore card.
2. Choose the storage and press Show snapshots.
3. Find the one you want and press Restore this snapshot.
4. Choose what to put back, then confirm.

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.

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 storage table shows your target as ready, 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.
• 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.
• You run more than one project here — every backup covers every project, but restoring from the panel puts back the first project. Ask support before restoring on a server with several.

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