How to roll a site back to an earlier date

A restore that fixes something broken and a rollback to a specific earlier date use the same underlying mechanism for a different reason. Restoring a website backup covers the case where something is wrong right now and you want the most recent working copy available. This page covers a more deliberate case: the most recent copy is not what you want, because you know the site looked right on a particular date in the past, and you want it back exactly as it stood then.

Start with the actual date, not a rough guess

"Sometime last month" is not precise enough to act on. Narrow it down using whatever evidence you have: a specific email that references the old state, a post or product you know was published before the change, a migration or import you remember running, or a plugin you know was installed after the point you want back. The more precisely you can pin the date, the easier the next step becomes, and the less likely you are to restore to a point that turns out to be a day or two off from what you actually needed.

Check how far back your backups actually reach

Most backup systems, including ours, keep a rolling window of recent backups rather than every one ever taken, and older backups are removed as new ones are created to make room. How long backups are kept covers why retention works this way and how to check the window for your specific plan, since it varies and can change over time — the client area or a direct question to support will give you the accurate figure for your account rather than a general assumption.

If the date you need falls outside that window, the only realistic path back is a copy you personally downloaded or exported yourself at some point, kept somewhere off the hosting account. This is one of the clearest practical reasons to keep an independent archive rather than relying only on an automated on-account schedule.

Understand what rolling back actually costs you

Before you go ahead, work out whether anything created since your target date is worth keeping. If it is, export or note it down separately first, in the same way you would back up the current, broken state before restoring in an emergency — the difference here is that you have the luxury of doing this calmly, since a deliberate rollback rarely has to happen in the next five minutes.

Match files and database to the same point in time

A website is files and a database working together, and a rollback that mixes a file backup from one date with a database backup from another can leave the two out of step with each other — a plugin the files expect to find configured a certain way, referencing a database structure that has since changed, or the reverse. Wherever possible, restore both halves from the same snapshot, taken at the same time, rather than assembling a rollback from separately dated pieces.

Test it on a copy first, if you can

Because a deliberate rollback is planned rather than an emergency, you are usually in a better position than a genuine outage to test first. Creating a staging copy of your site covers setting one up, and restoring your chosen date there first lets you confirm it is genuinely the version you wanted before you commit the same change to the live site.

Perform the rollback

Restoring a website from a backup covers the mechanics in full, through your control panel or by hand with FTP and a database import. The only difference for a deliberate rollback is which restore point you choose: instead of picking the newest available snapshot, select the one that matches your target date specifically, and confirm the date shown before you proceed.

If you only need part of the site rolled back

A full rollback throws away everything since the target date, including unrelated progress that had nothing to do with the problem you are trying to undo. If only one page, post, or file actually needs to revert, a full site rollback is more than the situation calls for. Restoring a single file covers pulling one item out of an archive without touching anything else, and restoring a database backup covers the equivalent for database content specifically. Reach for one of those first if the change you are undoing is narrow, and keep the full rollback for when the whole site genuinely needs to go back in time together.

After the rollback

• Check the date, not just that the site loads. Confirm the content actually matches the point you intended, not a neighbouring backup taken a day or two either side.
• Expect some things not to roll back with the site. Payment records at a payment provider, subscriber counts in an email platform, or analytics data live outside your hosting account and will not match the older date, even though the site itself now does.
• Clear caches, both any caching layer the site uses and your own browser, so you are not looking at a cached copy of the version you just replaced.
• Redo anything you deliberately preserved from after the target date, now that the rollback itself is done.

If the result still does not look like the date you intended, contact support with the exact date you were aiming for and the backup you restored, so we can help confirm whether the right restore point was actually available.