Blog · 7 November 2026 · 9 min read

Website backup: what you really have, what you don't, and a 15-minute check

Ask a business owner “do you have a backup of your website?” and the answer is almost always “yes”. The trouble is that “yes” usually means one of three things: “the host does backups, I think”, “the developer has the files on their laptop” or “there is a ZIP from 2023 somewhere”. None of these is a backup in the sense that saves a business after a hack, a failed update or someone deleting half the product catalogue. Below: what a backup must contain, what hosts actually promise (with quotes), how many copies to keep and where, and a 15-minute check that shows whether you have anything to go back to.

Three things owners mistake for a backup

  1. “The host does backups.” It does – for itself. A host's system backups exist so the host survives a failed disk, not so you can roll your site back to the state before Tuesday's plugin update. One large Polish host says it plainly: system backups “are made in case of storage media failure and do not replace the user's own backups”, and they are kept “for at least 48 hours”. If you notice a hack on Thursday that happened on Monday, the host's copy already contains the hacked site. Retention windows differ between hosts, but the pattern is the same everywhere.
  2. “The developer has the files.” The developer has the theme files from launch day. They do not have: the database with your posts, orders and customers, the photos you uploaded over two years, plugin settings, or the pages you edited yourself. A site rebuilt from the developer's files is an empty site with your logo.
  3. “There is a ZIP on my drive.” A copy with no date, no database and no proof it even unpacks is not a backup – it is hope. The WordPress handbook recommends backing up the automatic backups “with a manual backup once in a while to guarantee that the process is working”. A backup nobody has ever opened has unknown value.

What a website backup must contain

The WordPress documentation puts it in one sentence: “There are two parts to backing up your WordPress site: Database and Files. You need both to be able to fully restore a typical WordPress site.” The same holds for every CMS and shop platform you host yourself (Joomla, PrestaShop, WooCommerce, Magento).

  • The database – content, products, orders, users, plugin settings, menus. This is the part the developer usually does not have and that cannot be recreated by hand.
  • The files – theme, plugins, the uploads folder with your images and documents (wp-content/uploads in WordPress), the configuration file with database credentials (wp-config.php) and .htaccess or the equivalent server config with your redirects. The handbook singles out wp-content and wp-config.php, and says of the WordPress core files that “normally, there would be no need to copy the WordPress core files, as you can replace them from a fresh download”.
  • What a “website” backup usually does not include, and you still need somewhere: mailboxes (a site backup does not contain e-mail), the domain's DNS settings (a screenshot of the panel is enough), the list of accounts and logins (hosting, domain, CMS, Search Console, ad accounts), API keys and integration credentials (payments, shipping, invoicing).

What hosts actually promise

We read the public help pages and offers of four hosts popular in our home market, Poland (as of 7 November 2026). The picture will look familiar wherever you host:

  • One host keeps daily system backups “for at least 48 hours”, states they “do not replace the user's own backups”, and makes data from them available only as a separate IT service; longer retention and self-service restore are a separate paid product.
  • Another makes a daily backup “kept for 30 days on an external backup server” that includes “all site files and the database”; restoring is self-service over FTP plus a database import, and the same page warns that if an infection “has been present for longer than a month, restoring a backup from the last 30 days will not bring the expected results”.
  • A third documents how to share a backup from the panel and download it over SSH with wget, but publishes no retention period.
  • For the fourth we found no public system-backup policy at all, only a paid cloud backup add-on.

The common shape: a short window, restoring takes skills or money, and responsibility for the data is yours. The WordPress handbook says the same from the other side: “Most hosts back up the entire server, including your site, but it takes time to request a copy of your site from their backups, and a speedy recovery is critical. You need to learn how to back up your own site files and restore them.”

The 3-2-1 rule in plain words

The US cybersecurity agency CISA (formerly US-CERT) defines the 3-2-1 rule as: “3 – Keep 3 copies of any important file: 1 primary and 2 backups. 2 – Keep the files on 2 different media types to protect against different types of hazards. 1 – Store 1 copy offsite.” For a business website in 2026 that means:

  • 3 copies: the live site on the server (primary) + an automatic backup from a plugin or the hosting panel + a copy outside the hosting account.
  • 2 media: the hosting server is one. The second is cloud storage (Google Drive, Dropbox, OneDrive) or an external drive at the office. WordPress recommends exactly this layout: “one on your hosting server, one on cloud storage (Google Drive, Dropbox, etc.), and one downloaded to your local computer.”
  • 1 offsite: outside the host. A backup on the same hosting account disappears together with the site when the account is hijacked, suspended over an unpaid invoice, or when the host has an outage.

How often? WordPress: “For smaller websites with fewer posts, backups should be made once a week”, “for high-activity websites with a lot of posts, backups should be made daily”, and back up the database “always before an upgrade”. A simpler rule for a shop: as often as orders arrive that you cannot afford to lose. Keep “at least 3–5 recent WordPress backups” – one may be corrupted, and a hack noticed after a week needs a copy older than a week. CISA adds a line that applies to every business: “Maintain offline, encrypted backups of data and regularly test your backups.”

The 15-minute check: do you have anything to go back to?

  1. Find the latest backup (3 min). Log in to the hosting panel and look for “Backups”. If you have a backup plugin in WordPress (UpdraftPlus, BackWPup, Duplicator, Jetpack VaultPress), open its list. Write down the date of the newest copy. If there is none from today or yesterday, the check is over – you have your answer.
  2. Check what is inside (5 min). Download the newest backup and unpack it. Look for two things: a database file (.sql or .sql.gz) and the uploads folder (wp-content/uploads or its equivalent). No .sql file means a backup without content or orders. Open the .sql file in a text editor and search for yesterday's post title or the last order number – if it is not there, the backup is old or incomplete.
  3. Check where it lives (2 min). If the only location is the same server as the site, move the newest copy to cloud storage now, by hand. Then set the plugin or panel to send backups off the host automatically.
  4. Ask about restoring (5 min). Send your host or developer one question: “If I reported at 9:00 today that the site is destroyed, by what time and at what cost would it be restored to yesterday's state?” An answer with a time and a price is fine. “It depends” means nobody has ever done it.

A full restore test (restoring the backup to a staging address and clicking through the site) is a job for the developer, 1–2 hours, once a quarter or after any major change. Only then do you know the backup works rather than merely exists.

Scenario → what saves you → what won't

What happenedWhat saves youWhat won't
A plugin update broke the siteYesterday's backup of files and database; in WordPress, disabling the plugin over FTP is often enoughLast month's backup – you lose 30 days of content and orders
A hack noticed a week laterA backup older than the hack (at least 2 weeks back) + updates + new passwords; Google's advice is to “replace affected files with the last good backup”The host's 48-hour backup – it already contains the hacked site
Someone deleted products or pagesA database backup from before the deletion; a developer can restore just those recordsA files-only backup (theme, plugins) – the content lives in the database
Hosting account suspended or hijackedA backup outside the host (cloud/drive) + access to the domain to point it at a new serverBackups kept on the same hosting account
The developer disappearedYour own backup + the list of logins (hosting, domain, CMS) in your hands“They have everything on their laptop”
Mailboxes are goneA separate e-mail backup (a mail client with a local copy, or an archive)The website backup – it does not contain e-mail

Questions for your host and developer (copy and paste)

  • How often do you back up my site and how long do you keep the copies? Do they include the database?
  • Can I restore a backup myself from the panel, or is it a support ticket? What does it cost and how long does it take?
  • Where are the backups physically stored – on the same server as the site or elsewhere?
  • When did someone last restore my site from a backup, and did it work?
  • (Developer) Do you take a backup before every update, where do you store it, and will I have access to it?

What Webskan checks

A backup is invisible from the outside – we cannot tell whether you have one. We look at what customers and Google can see, and at what changes. The in-depth audit flags server headers that reveal software versions (they make the attack that will make you need a backup easier) and publicly accessible files that should never sit under your website's address: database dumps, backup archives, configuration files and a .git repository – a backup inside the web root is a data leak, not a safeguard. Webskan Monitor checks the site every day, stores a screenshot of the home page and compares it with yesterday's: when the site starts returning errors, shows empty content, redirects elsewhere or looks significantly different, you get an e-mail the same day – which is exactly the day a pre-incident backup still exists.

A quick picture, free

The free Webskan quick scan checks your site the way a customer's phone sees it: certificate and https redirect, basic security headers, performance and SEO. No e-mail, no sign-up, results in about 30 seconds.

Want someone to compare your site with yesterday's every day and write only when something changes? Webskan Monitor ($15/month); 30 days of Monitor included with the in-depth audit ($69).

Sources and tools