The right question is not “how many copies” but “how far back do I need to be able to go”. The answer is: at least as far as the time it can take you to notice damage. Our automatic copy covers the last 30 days (how it works). The copies you make yourself exist to cover what lies beyond that, and the day the account is no longer there.
Many recent ones, few old ones
The classic scheme keeps many recent copies and fewer and fewer old ones: dailies for yesterday’s mistakes, weeklies for what was noticed late, monthlies for slow damage. That covers a long time without keeping a copy per day for years. A sample plan, which you adjust to your case (the numbers are an example, not a recommendation):
| Copy |
When it is made |
How long it is kept (example) |
What it is for |
| Daily |
Every night. |
A few days. |
Yesterday’s mistake. We already have it, in JetBackup. |
| Weekly |
One fixed day a week. |
A few weeks. |
What was only noticed mid-month. |
| Monthly |
The 1st of each month. |
Several months. |
Slow damage, or an old lookup. |
| Before a big change |
When you are about to make it. |
Until the change has settled. |
Going back to the starting point of an update or a migration. |
How to decide your plan
| 1 |
Measure a full copy. Look at the space in use under Disk Usage. Multiply by the number of copies you want to keep: that is the space they take, and it counts against the plan if they stay in the account (the limits nobody advertises).
|
|
| 2 |
Ask yourself how long it takes to spot a problem. On a shop you see it within hours. On a little-visited blog, a month can pass. The later you find out, the further back you must be able to go.
|
|
| 3 |
Pick the cadence by what you lose if it fails. If losing a day of orders costs money, a daily copy. If the site changes once a month, a monthly copy and one before each change are enough.
|
|
| 4 |
Automate the clean-up, not only the copy. If your backup script does not delete old ones, the disk fills and the next copy fails with nobody watching. The script is in automatic backups of your own application.
|
|
| 5 |
Keep the ones that matter longest somewhere else. Old ones do not need to sit in the account: take them out (off-site backups) where they do not use your space.
|
|
|
Test the clean-up before letting it delete. A find ... -mtime +N -delete command with the wrong path deletes what it should not. Run it first with -print instead of -delete, read the list, and only then swap.
|
|
Keeping everything forever is also a decision about personal data. An old copy holds customers’ data as it was, including people who have since asked to be erased. Decide how long you keep copies and stick to it (data protection on your website).
|
|
Put the date in the name in year-month-day form (2026-10-10). They sort themselves and the oldest is obvious at a glance.
|
|
Want help working out which copies you already have from us and which are missing? Write to us.
Open a support ticket
|
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from $6.59/mo (3-year plan, with coupon) See plans |
Português
English
