Restoring a backup: what to know beforehand

Restoring a backup starts with stopping: do no further work on the site, note when everything was still working, and decide whether you want the files, the database or both restored. With that information you request the restore from support. At WWW4 a backup of files and database is made every day and kept for 14 days. So you cannot go back further than 14 days, and everything that changed after the chosen point in time is overwritten.

When restoring is the right choice

• An update of a plugin, a theme or the CMS has broken the site and you cannot get it repaired.
• Files were deleted or overwritten by accident, for example over FTP.
• Content has disappeared: pages, products or settings that lived in the database.
• The site has been hacked. In that case also follow the steps in your website has been hacked, because restoring a backup does not close the hole.

If you know which plugin causes the error, deactivating it is quicker and you lose nothing.

What to note down first

The moment you need a backup is usually the moment you are not thinking clearly. So follow this order.

1. Stop working on the site. Every change you make now will be lost in the restore, or will make it harder to work out exactly what went wrong.
2. Establish when it was still working. This is the most important piece of information. The more precisely you know it, the more targeted the restore can be.
3. Write down what went wrong. Which action came before it, which error message you see, and on which pages.
4. Decide what you restore: the files only, the database only, or both.
5. Note what has been added since. Orders, comments, form submissions, new pages. That is what you may have to enter again after the restore.

Files, database or both?

A site built on a CMS such as WordPress consists of two parts. The files are the CMS itself, the themes, the plugins and the images you uploaded. The database holds the content: pages, posts, products, orders, comments, users and settings.

• A broken update of a plugin or theme usually needs the files only. If the update also changes the database, the database from the same point in time has to be restored with it.
• Missing content needs the database.
• A hack, or a problem you cannot place, needs both, from the same point in time.

Restoring both means you also lose new orders or comments from after that point. So never choose more than you need.

Requesting the restore from support

1. Get in touch with support via contact or by phone.
2. State the domain name, what went wrong, the time at which the site was still working, and whether you want the files, the database or both restored. If it concerns a single database or a single folder, say so.
3. Do not change anything else on the site until you hear that the restore has been carried out.
4. Then check the site: the home page, a few underlying pages, signing in to the admin area, a form and, for a web shop, a test order.

What a restore overwrites

A restore puts the chosen part back to the state of the backup. Everything that changed in that part afterwards is gone. Nothing is merged.

If you want to keep data from after the backup, make your own copy of the current state before the restore. Export the database through phpMyAdmin, or the orders from your web shop, and download the files you added recently.

After the restore: find the cause

Find out what caused the problem. Otherwise you will be restoring the same problem again next week. If it went wrong after an update, do not simply run that update again: first read how to do WordPress updates safely. If it was a hack, change all passwords and update everything before you carry on, because the backup contains the same hole as before.

Your own backups alongside your host's

The daily backup of your hosting is a safety net for the past 14 days. If you only discover a problem after three weeks, every backup that is still kept contains the problem too.

• Make your own copy before every major change: a CMS update, a new theme, an import.
• Download the files over FTP or the file manager and export the database through phpMyAdmin, or use a backup plugin that writes to external storage.
• Keep those copies outside your hosting. A backup stored in the same place as the site takes up web space and disappears together with the site.

How to build that up is explained in a backup strategy that goes beyond a single copy. What exactly WWW4 keeps is set out on backup and restore.

Frequently asked questions

How far back in time can I go?

The daily backups of files and database are kept for 14 days. If you need an older version, you depend on your own copies.

Can I have only the database restored?

Yes. State in your request that it concerns the database only, and which database if you have several. The files then stay as they are.

Do I still need to make backups myself if my host does it every day?

Yes. The host's backup protects against problems you notice quickly. Your own copy outside the hosting protects against what you only discover late.

Still stuck?

If you are unsure which point in time or which part to choose, describe what happened and when via contact. We will look with you at which backup fits best.