Published
A complete website contains more than pages
A WordPress backup needs to account for both files and the database. Files include uploads, themes and plugins. The database holds items such as posts, page content and settings. Exporting posts alone is not the same as making a complete recovery copy. Check which components your chosen backup method actually includes.
Match the frequency to your changes
A rarely changed website has different recovery needs from a shop receiving orders every day. Consider how many recent changes you could afford to lose during recovery. Make a suitable copy before a major update or change as well. Drechthosting lists daily backups as an additional recovery option with web hosting. Ask about available restore points and the procedure for your plan if you need certainty.
Keep an independent recovery point too
Ask where the copy is stored and who can access it. A separate copy can be useful if you do not want your only recovery option to depend on the same hosting environment. Protect backups because they can contain customer information and settings. Do not share an archive through a public link. Align retention with your business policy and remove obsolete copies deliberately.
Test restoration in a suitable environment
Do more than check that a task reported success. Where possible, test a restoration in an isolated test environment. Check pages, images, forms and login afterwards. For an online shop, also check which orders and other records belong to the restore point. Never casually replace current orders with an old database. Ask for help if the consequences are unclear.
Record who does what when something goes wrong
Note who can access backups, how to request support and which information to collect first. A developer can help restore the website; we help with questions about the hosting environment. A short recovery plan saves searching for files during an incident. Combine backups with maintenance: having a copy does not replace keeping your website updated.
