Where are WordPress backups stored? Wherever the tool that made them puts them, and WordPress itself makes none. Your host’s backups live in the hosting control panel or on the host’s own storage (Kinsta keeps them on the same machine as your site, WP Engine on Amazon S3). Backup plugins write into a folder under wp-content on your server unless you connect them to Google Drive, Dropbox or S3. Manual backups are wherever you saved the zip and the .sql file. That is the answer; the useful part is knowing which of the three you actually have, because a lot of site owners find out during a hack that the answer was “none”.
Does WordPress back itself up?
No. There is no backup feature in WordPress core, and the official backup handbook says as much: it describes how to export the database with phpMyAdmin and copy the files, and then points you at hosts and plugins. In practice that is phpMyAdmin, select the database, Export, SQL; then zip wp-content, wp-config.php and .htaccess over SFTP. When restoring, put the files back first, then import the database. If you have never set anything up and your host does not include backups, you have no backup. The only automatic safety net WordPress adds is the revision history inside each post, which restores text, not a site.
Where do hosting backups live?
Every managed host keeps backups somewhere you cannot reach with FTP; you restore or download them from the host’s dashboard. What differs is how often they run and how long they keep them, and those two numbers decide whether a backup is useful.
| Host | Where you find them | How often | Kept for |
|---|---|---|---|
| Hostinger | hPanel, Files, Backups | Weekly on Premium, daily on Business and above | Weekly backups kept about six weeks, daily ones about seven days; download a copy if you want one off the server |
| SiteGround | Site Tools, Security, Backups | Daily, automatic on every plan; on-demand copies on GrowBig and above | Up to 30 days of restore points |
| Kinsta (docs) | MyKinsta, site, Backups | Daily automatic, plus manual and system backups | 14 days on most plans, 20 or 30 on higher tiers; stored on the same machine as the site |
| WP Engine (docs) | User Portal, environment, Backups | Daily automatic checkpoints, plus manual before updates | 30 days, stored off-site on Amazon S3 and encrypted |
| Any cPanel host | cPanel, Backup or JetBackup | Depends on the host; some run none | Check the panel; if the section is empty, assume there are none |
Two cautions. A backup that sits on the same server as the site (Kinsta’s default, and every cPanel “full backup” you leave in your home directory) protects you from your own mistakes, not from the server failing. And “daily” on a shared plan often means “overwritten daily”, so the version from before the problem may already be gone by the time you notice it. Download a copy of a good backup to somewhere else at least once a month.
Where do backup plugins store their files?
Plugins write to a folder inside wp-content by default. You can see and download the files over SFTP or in your host’s file manager, which is also how you retrieve a backup when the dashboard itself is broken.
| Plugin | Default folder on the server | Off-site option |
|---|---|---|
| UpdraftPlus | /wp-content/updraft/ | Google Drive, Dropbox, S3 and others; free version includes Drive and Dropbox |
| All-in-One WP Migration | /wp-content/ai1wm-backups/ | Cloud destinations are paid extensions |
| Duplicator | /wp-content/backups-dup-lite/ | Cloud storage in the Pro version |
| WPvivid | /wp-content/wpvividbackups/ | Drive, Dropbox, S3, FTP in the free version |
| BackWPup | /wp-content/uploads/backwpup-*-backups/ | Dropbox, S3, FTP and email in the free version |
| Jetpack VaultPress Backup | Not on your server at all | Stored on Jetpack’s cloud; restore from the Jetpack dashboard |
The folder location is also the reason a plugin backup on its own is not enough: if the server is compromised or the account is suspended, the backup goes with it. Connect the plugin to a cloud destination, or at minimum download the latest file after each run. The same goes for the essential WordPress plugins that store settings in the database: they are only safe if the database is in the backup too.
What has to be in a backup for it to count?
Two things, and most people only have one. The database holds every post, page, comment, user, plugin setting and theme option; it is the .sql file. The files are wp-content (themes, plugins, uploads), wp-config.php and .htaccess. A copy of the files without the database restores an empty site; a database without the files restores text with no images and no theme. Host backups include both. Plugin backups usually do, if you left the defaults alone. A manual export from Tools, Export is neither; it is content only.
How do you check where your backups are right now?
- Log in to your host and look for a Backups section. Note the date of the newest one and how many are listed. If the section is empty, you have no host backup.
- In WordPress, open Plugins and look for any backup plugin. Open its settings and note the destination; “local” means the folder above, on the same server.
- Over SFTP or the host file manager, open
wp-contentand look for the folders in the table. Check the dates. - Ask yourself when a copy last left the server. If the answer is never, download one today.
- Test one restore on a staging copy. A backup that has never been restored is a hope, not a backup.
Do this once and write the answers down; you will want them the day something breaks. The people who lose sites are rarely people with no backup plan, they are people who assumed someone else had one. If a designer built your site, this is on the handover list along with the logins; which WordPress role to give your designer covers what else to take back at the end of a project.
Where should backups be stored, then?
Follow the 3-2-1 rule that most hosts’ own documentation quotes: three copies, on two kinds of storage, one of them off-site. In practice for a small business site that means the host’s automatic backup, a plugin backup sent to Google Drive or Dropbox on a weekly schedule, and a downloaded copy on your own computer or drive after any big change. None of it costs more than the free tier of a cloud drive. It is the first thing I set up on every WordPress site I build, before the design starts, because a site with no backup is a site you do not really own.
Frequently asked questions
Nowhere. WordPress core does not create backups. Host backups are stored in the hosting control panel or on the host’s storage; plugin backups are stored in a folder under wp-content on your server unless you connect a cloud destination.
In /wp-content/updraft/ on your server by default. You can connect it to Google Drive, Dropbox, Amazon S3 and other remote storage so copies also leave the server.
Most managed hosts do: Hostinger weekly on Premium and daily on Business, SiteGround daily with up to 30 days kept, Kinsta daily with 14 to 30 days kept, WP Engine daily with 30 days kept off-site. Check the Backups section of your hosting panel to confirm and note the retention.
The database (.sql) and the site files: wp-content with themes, plugins and uploads, plus wp-config.php and .htaccess. Both parts are needed to restore a working site.
From your host’s Backups panel, choose a restore point and download it; or open the plugin’s backup list and download the files; or copy the plugin folder under wp-content over SFTP.
Daily if you publish or take orders often, weekly for a brochure site, plus a manual backup before any theme, plugin or WordPress update. Keep at least one copy off the server.
