# Backups > Source: https://www.allsweb.com/sixpanel/docs/backups > Markdown for agents: https://www.allsweb.com/sixpanel/docs/backups.md > Publisher: AllsWeb (www.allsweb.com) Part of: SixPanel documentation **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. 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. ### 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: | The field in the panel | What goes in it | |---|---| | **Name (so you recognize it later)** | anything, for example `Backblaze offsite` | | **Endpoint (host only, no https://)** | the endpoint from step 3, for example `s3.us-west-004.backblazeb2.com`. No `https://`, no slash, no bucket name | | **Bucket** | the bucket name from step 2. A folder inside it is allowed too: `myshop-6ammart-backups/live` | | **Access key** | the **keyID** from step 5 | | **Secret key** | the **applicationKey** from step 5 | 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 | Result | What it means | What to do | |---|---|---| | **Passed** | The backup opened, and **every** project database in it loaded with the tables that must have rows having rows. | Nothing. | | **FAILED** | The backup opened but the data is not complete — too few tables, or a table that must have rows came back empty. | Treat your backups as unusable until this passes. See below. | | **Could not run** | The test could not start — usually not enough free disk, or no backup with a database in it yet. | Free space on **Server → Resources**, or run a full backup first, then test again. | | **Never tested** | Nobody has ever checked. | Press **Test my backup now**. | **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](https://www.allsweb.com/sixpanel/docs/troubleshooting).