Help Centre / Backups And Staging
How Backups Work
Every live website on Oxyforge is backed up automatically once a day. You do not switch it on, schedule it or pay extra for it. A suspended website is not backed up until it is active again. The last 30 days are kept, so you can go back to any day in the last month.
That covers the ordinary bad day: a plugin update that breaks a page, an editor who deletes the wrong thing, a theme change that went further than expected.
What Is In A Backup
A backup is the whole website, in two parts.
- The files. WordPress itself, your theme, your plugins, and everything in your uploads folder.
- The database. Your pages and posts, settings, users, comments, and on a shop your orders and customers.
Both halves are taken together, so the pair matches. That matters more than people expect. A database restored next to files from a different day is how you end up with a site that half works.
When They Are Taken, And How Long They Last
| Daily backup | On-demand backup | |
|---|---|---|
| Who starts it | The platform | You |
| How often | Once a day, automatically | Whenever you like |
| Kept for | 30 days | 30 days |
| Counts toward storage | No | No |
After 30 days the oldest backup drops off as a new one arrives. If you need something kept longer than a month, take your own copy and keep it yourself (see below).
Taking One Yourself
You can take a backup on demand from the website’s backups list, up to one every 15 minutes, and not while another job is running on the site. How long it takes depends on the size of the site.
Do it before anything you would not want to undo by hand:
- A WordPress, theme or plugin major version update.
- Installing or removing a plugin that touches the database, which includes most page builders, shop plugins and SEO plugins.
- Editing theme files or a child theme.
- Any bulk change to content.
The platform also takes a backup for you before anything that overwrites a site: before a restore, before a primary domain change, before a staging push to live, and before an automatic WordPress update. Those are the moments where a mistake is hardest to unpick, so you get a point to return to whether you remembered or not. They appear in the list as Safety Copy.
Backups Do Not Use Your Storage
This is the question we get most, so to be plain about it: backups are stored separately and do not count toward your storage allowance. A site with 30 days of history uses the same storage as one with none.
Your storage allowance is your live files plus your live database, pooled across the websites on your account. See storage explained.
Taking your own copy over SFTP is different. Those files travel out to you over the internet, so they count toward your bandwidth like any other download. See bandwidth explained.
Keeping A Copy Of Your Own
The backups in the members area are for restoring. They are not offered as a download. To hold a copy somewhere we do not control, take it from the live site: pull the files over SFTP and export the database with WP-CLI (wp db export), then keep both on your own machine or in your own cloud storage.
Backups here are an operational safeguard, not a guarantee. They are designed to get a site back after an ordinary mistake, and they do that well. They are not a substitute for your own copy of anything you could not recreate. If losing it would be serious, you should hold a copy somewhere we do not control.
That is not a disclaimer we are hiding in small print. It is the honest position for any host, including the ones that do not say it. A month of restorable history plus one copy of your own, kept somewhere else, is a sensible arrangement for a site that matters.
Deleting A Website
When you delete a website it goes offline and leaves your account straight away. Its files, database and backups are not destroyed at that moment: we keep an archived copy for 30 days.
You cannot undo a deletion yourself. If you deleted the wrong site, open a ticket from the members area within 30 days and we restore it. After 30 days the archive may be removed permanently and the site is gone for good.
The same applies if you delete a site to free up a website slot. If there is any chance you will want it again, take your own copy of the files and database first rather than relying on the 30-day hold.
Restoring Part Of A Site
You do not have to take the whole thing back. A restore can be the whole site, only the files, or only the database.
| What you restore | Use it when |
|---|---|
| Files and database | A broken update, a hack, or you genuinely want yesterday back |
| Files only | A plugin or theme change broke the site but your content is current |
| Database only | Content or settings were damaged but the files are fine |
Files only is the one people reach for most on a live shop, because it fixes the code without rolling back orders that have come in since. The steps are in restore a backup.
Backups Are Not The Same As Staging
A backup is a copy of the past. Staging is a place to work on the future. They solve different problems and you want both.
If you are about to make a change you are not sure about, staging is the better tool: you try it on a copy and nobody sees the mess. A backup is what you reach for when the change is already live and already wrong. See create a staging site and push it live.
A staging copy is a working area, not a safety net. Do not treat the existence of one as your backup.
Where To Find Them
Open the website in the members area and go to its backups list. Each entry shows the date it was taken and lets you restore it, whole or in part.
If a backup you expect is not there, or a restore does not behave the way this page describes, open a ticket from the members area with the website name and the date you are after.
Did this answer it? If not, open a ticket from the members area and someone who runs the platform will pick it up.
Open A Ticket