# How to Stop Backups From Being Auto Deleted and Back Up Daily and Weekly (xCloud v2.9.9)

> Stop backups from being auto deleted with Skip Delete, and run daily, weekly and monthly backups to one destination. What changed in xCloud v2.9.9.

To **stop backups from being auto deleted** in xCloud, open the site's **Previous Backups** page and choose **Skip Delete** on the backup you want to keep. Since v2.9.9, auto delete and **Backup Retention** leave it alone until you choose **Allow Delete**. A site can also run full backups daily, weekly and monthly at once.

Retention is a good habit with one blind spot. It deletes on a fixed clock, and the clock does not know which backup mattered. The backup you took right before a big update, a theme switch or a migration looks the same to it as any other.

This post explains why that happens, how **Skip Delete** and **Backup Schedules** fix it, and the limits worth knowing before you rely on them. For the click-by-click steps, the [**Skip Delete and multiple backup schedules guide**](/docs/keep-a-backup-and-run-multiple-backup-schedules-in-xcloud/) has every screen.

![How to stop backups from being auto deleted: the Skip Delete option in a backup's menu on the xCloud Previous Backups page](/_landing/blog/keep-important-backups-and-back-up-daily-and-weekly-on-xcloud-image-1.png)

## TL;DR

Short on time? Here is the whole update in a few lines:

- **Skip Delete** keeps any completed backup out of auto delete, in the list, on the server and in your bucket, until you choose **Allow Delete**.
- A kept backup **can't be deleted by accident**. You turn Skip Delete off first.
- **Backup Schedules** lets one destination take full backups on any mix of **12 Hours**, **Daily**, **Weekly** and **Monthly**.
- **Retention is shared.** A weekly backup is not kept longer than a daily one. Use Skip Delete for the ones you want to hold.
- **Incremental destinations** run one schedule, and keeping one incremental backup keeps its whole set plus every newer one.
- Both features were added in [**xCloud v2.9.9**](/changelog/v2-9-9/). Backup Schedules needs a paid plan.

## What Skip Delete Protects, and What It Doesn't

Here is the one thing most backup guides skip: what a "keep" flag actually survives. The table below comes from how xCloud's cleanup works today, and it is the part to read before you trust it with a backup you can't lose.

| Action | What happens to a kept backup |
|---|---|
| **Auto delete and Backup Retention** | Skipped. It stays in the list, on the server and in the bucket. |
| **Delete Selected** or a single delete | Blocked until you choose **Allow Delete**. |
| Removing the destination with **Also delete the backups already stored there** ticked | **Not protected.** The files go with the destination. |
| Deleting the site | **Not protected.** |

If you only remember one line: **Skip Delete guards against the clock, not against you removing the whole destination or site.** Keep a downloaded or off-server copy of anything you could not rebuild.

## Why Retention Can Delete the Backup You Need

**Backup Retention** keeps backups for a set number of days, then auto delete removes the older ones. That keeps storage costs flat, and it is the right default for most sites.

The catch is timing. Say retention is 7 days and you took a backup before a large plugin update. A problem shows up 10 days later, in a checkout flow nobody tested. By then the clean backup from before the update is gone.

The [**WordPress backup guide**](https://developer.wordpress.org/advanced-administration/security/backup/) says to back up your database "regularly, and always before an upgrade". It also suggests keeping several recent backups in different places. Retention alone can't promise the first part survives long enough to be useful.

Before v2.9.9, the only ways around this were a longer retention period for every backup, or downloading the backup by hand. Both work. The first fills your storage, and the second depends on someone remembering.

## Keep a Backup With Skip Delete

Skip Delete works on any completed full or incremental backup, local or remote. It keeps the whole backup: the files archive and the database dump together.

1. Open the site in xCloud and go to **Site Backup → Previous Backups**.
2. Open the menu at the end of the backup's row and choose **Skip Delete**.
3. To keep several at once, tick them and click **Skip Delete (n)**.

A **Skip delete** badge appears on the row, and xCloud confirms that auto delete skips these backups.

![The Skip delete badge on a kept backup, with the blocked Delete Selected button and its tooltip in xCloud Previous Backups](/_landing/blog/keep-important-backups-and-back-up-daily-and-weekly-on-xcloud-image-3.png)

When you no longer need it, choose **Allow Delete** in the same menu. The next auto delete run then removes it if it is past your retention period, unless it is your newest backup.

A few backups can't be kept. A failed backup has nothing worth holding, and Docker app backups follow [**their own retention**](/docs/backup-and-restore-docker-apps/).

## Run Daily, Weekly and Monthly Backups Together

One schedule used to force a choice. Frequent backups meant short history, and a long view meant gaps between backups. **Backup Schedules** removes that choice for full backups.

1. Go to **Site Backup → Backup Settings** and pick the **Local Backup** or **Remote Backup** tab.
2. Set the backup type to **Full** and turn on **Automatic Backup**.
3. Under **Backup Schedules**, select one or more of **12 Hours**, **Daily**, **Weekly** and **Monthly**. At least one stays selected.
4. Save the settings.

![xCloud Backup Settings with Backup Type Full, Automatic Backup on, and Daily and Weekly selected under Backup Schedules](/_landing/blog/keep-important-backups-and-back-up-daily-and-weekly-on-xcloud-image-2.png)

**Previous Backups** then shows the next run of each schedule. Every schedule saves to the same destination, and you restore any of them the same way, including [**to another site**](/docs/how-to-restore-a-backup-to-another-site/). You can also [**recreate a whole website from a backup**](/how-to-recreate-websites-from-backups/).

Two details keep this predictable. Schedules on one destination never back up the same site at the same moment, and **Backup Now** follows the same rule. Backup Settings, including Backup Schedules, needs a paid plan.

## How Retention, Storage and Incremental Backups Work With Both

This is where people expect one thing and get another. Here is the full picture in one table.

| Question | Answer |
|---|---|
| Does a weekly or monthly backup stay longer than a daily one? | **No.** All schedules of a destination share one **Backup Retention** period. |
| How do I keep a monthly backup for a year? | Set that backup to **Skip Delete**. |
| Can an incremental destination run several schedules? | **No.** It runs one **Automatic Full Backup** schedule. |
| What does keeping an incremental backup keep? | The whole set: the full backup and every incremental backup up to the next full one. |
| Does keeping an incremental backup affect newer ones? | **Yes.** Auto delete stops removing newer backups on that destination until you choose **Allow Delete**. xCloud asks first. |
| Do kept backups cost storage? | **Yes.** They stay until you allow delete. |
| Do team backup defaults set several schedules? | **No.** [**Global backup settings**](/docs/global-backup-settings-with-xcloud/) and bulk apply still set one schedule per site. |

The incremental rule is there for a reason. An incremental backup can't be restored without its full backup, so xCloud keeps the set together. The [**incremental backup guide**](/docs/incremental-backup-in-xcloud/) explains how those sets are built.

Rule of thumb: use schedules for a steady history, and use **Skip Delete** for the few moments you know you may come back to.

### A simple plan that uses both

Treat this as a starting point rather than a strict rule:

- **Daily** schedule with a retention period you are comfortable paying storage for.
- **Weekly** schedule on the same destination, so a quiet week still has a clean point.
- **Skip Delete** on the backup taken right before each major update or migration, then **Allow Delete** once the change has run cleanly for a few weeks.
- A second destination off the server for anything critical. [**Manage storage providers and backups**](/how-to-manage-storage-providers-backups-with-xcloud/) shows how to add one. See the [**backup best practices**](/docs/optimal-backup-practices-xcloud/) and the [**5 website backup mistakes**](/website-backup-mistakes/) worth avoiding.

## Honest Limits

Both features solve a specific problem, and it is worth being plain about the edges.

- **Skip Delete is not an archive.** Removing the destination with its files, or deleting the site, still removes kept backups.
- **Schedules don't change retention.** If you want monthly backups for a year, you keep them by hand with Skip Delete.
- **Storage grows.** Every kept backup, and on incremental destinations every newer backup, stays until you allow delete.
- **To undo:** choose **Allow Delete** to hand a backup back to retention, and deselect extra schedules to return to one.

If an automatic backup is not running at all, that is a different problem. Start with [**how to solve automatic site backup failures**](/docs/how-to-solve-automatic-site-backup-failures/).

## Other Fixes in v2.9.9

The same release fixed a few things you may notice:

- **Cloning a site from a private Git repository** now sets up its deploy key on GitHub by itself, or asks you for it on the **Confirm** step, instead of doing nothing on **Start**. See [**how to clone a Laravel app**](/docs/how-to-clone-a-laravel-app-with-xcloud/).
- **Object Cache Pro** sites no longer empty their whole object cache on every page load, so cached data lasts between requests.
- **SSH keys** can now be searched by name or fingerprint, across every page.

The [**v2.9.9 changelog**](/changelog/v2-9-9/) lists every change, including the developer details for the Public API and MCP.

## Start Keeping the Backups That Matter Today

Retention is still the right default. It just needed a way to hold the few backups that carry real risk, and a way to take frequent backups without losing the long view.

This week, open your busiest site and add a **Weekly** schedule next to the daily one. Then, before your next big update, take a backup and set it to **Skip Delete**. If you are setting backups up for the first time, start with [**site backups in xCloud**](/docs/site-backups-in-xcloud/) and [**how to automatically back up your website**](/how-to-automatically-backup-your-website/).

Backup Settings, including Backup Schedules, needs a paid plan. Compare plans on the [**xCloud pricing page**](/pricing/).

If you have found this blog helpful, feel free to [**subscribe to our blogs**](https://xcloud.host/blog/) for valuable tutorials, guides, knowledge, and tips on web hosting and server management. You can also join our [**Facebook community**](https://www.facebook.com/groups/xcloud.community) to share insights and engage in discussions.

## Frequently Asked Questions

### How do I stop backups from being auto deleted in xCloud?

Open the site, go to Site Backup → Previous Backups, open the backup's menu and choose Skip Delete. Auto delete and Backup Retention then leave it in the list, on the server and in your storage bucket until you choose Allow Delete.

### Does a weekly backup stay longer than a daily one?

No. All schedules of a destination share its Backup Retention setting, so weekly and monthly backups are kept for the same number of days as daily ones. To keep one longer, set it to Skip Delete.

### Can I still delete a backup that is set to Skip Delete?

Not until you turn Skip Delete off. Choose Allow Delete on the backup first, then delete it. Removing the whole destination with its files, or deleting the site, still removes it.

### Can incremental backups run on several schedules?

No. An incremental destination builds one linked set of backups, so it runs one Automatic Full Backup schedule. Several schedules are offered when the backup type is Full.

### Do kept backups use more storage?

Yes. A kept backup stays until you choose Allow Delete, so it keeps using space. On an incremental destination, every newer backup on that destination stays too, so check your storage after keeping one.