A backup is not a file. It is a demonstrated ability to get your site back, and the only way to know you have one is to restore it. Plenty of sites have run backup plugins for years, discovered a problem, and found the archives were incomplete, unreadable, or stored on the same disk that just failed. The plugin reported success every time.
This covers what a WordPress backup has to contain, where it has to live, how long you need to keep it, and the restore drill that turns the whole arrangement from a hope into a fact.
What a complete backup contains
A WordPress site is two things, and both are required. The database holds your posts, pages, comments, users and every setting. The files hold WordPress itself, your themes, your plugins and the uploads folder with every image you have ever added.
Restoring one without the other does not work. A database restored against different files gives you posts that reference a theme that is not there and images that do not exist. Files restored without the database give you an empty site.
Of the files, wp-content is what genuinely cannot be replaced. WordPress core can be downloaded again, and plugins can be reinstalled. Your uploads, your customised theme and wp-config.php cannot.
Where a backup has to live
A backup stored only on the same hosting account is not a backup. It protects you against a bad update or a deleted page, which is genuinely useful. It protects you against nothing else. If the account is compromised, the attacker can reach the archives. If the disk fails, both copies go together.
Keep at least one copy somewhere else: cloud storage, another server, or your own machine. Most backup plugins can push to remote storage automatically, and this is the setting worth spending time on.
The rule that survives every scenario: at least two copies, at least one of them somewhere the site cannot reach.
How often, and how long to keep them
Frequency follows from a single question: how much work are you willing to redo? A site publishing weekly can back up weekly. A store taking orders hourly needs something much closer to continuous, because a day-old backup means a day of lost orders.
Retention is the part almost everyone gets wrong. Keeping three days of backups feels sufficient and is not, because compromises and slow corruption are usually discovered long after they start. If a site was infected two weeks ago and you have three days of copies, every copy contains the infection.
Keep daily copies for a week or two, weekly copies for a couple of months, and a monthly copy for longer. That way there is always a copy from before whatever you eventually discover.
Backing up with a plugin
A backup plugin is the practical choice for most sites: schedule it, point it at remote storage, and let it run. Choose one that backs up files and database together, supports remote destinations, and can restore, some create archives but leave restoring to you, which is a poor trade when you need it most.
Set the schedule to match how often the site changes, configure the remote destination, and set retention deliberately rather than accepting the default. Then verify the first backup actually arrived at the remote destination. A plugin reporting success while the remote upload silently fails is common, and the failure surfaces only when you need the file.
Backing up through cPanel
cPanel can produce a full account backup, covering every site on the account plus email and settings. It is the most complete option and the least convenient for routine use, because it is one large archive that you download by hand.
It is the right tool before a risky change: a PHP version jump, a major WordPress release, a migration, where you want a known-good copy of everything from one moment. Creating and restoring backups in cPanel explains the interface.
Do not rely on it alone for scheduled protection, and do not assume your host's own backups are yours to depend on. Host-level backups exist for infrastructure recovery, and their retention is not chosen around your needs.
Backing up manually
Worth knowing because it always works when a plugin will not.
For files: compress the site directory in File Manager and download the archive. At minimum take wp-content and wp-config.php.
For the database: open phpMyAdmin, select the database, and export it as SQL. Take the whole database rather than selected tables.
Keep the two files together and name them with the date. A files archive and a database dump from different days will not restore into a consistent site.
The restore drill
This is the part that makes the rest real, and the part almost nobody does.
Restore your most recent backup into a place that is not your live site; a subdomain, a staging install, or a local environment. Then look at it properly: does the homepage render, are recent posts present, do images load, does the admin area work?
You are checking for specific, common failures. An archive that is missing the uploads folder because it exceeded a size limit. A database export truncated by a timeout. A plugin whose licence does not activate on a restored copy. Every one of these is discoverable in fifteen minutes now, and discovered at the worst possible time otherwise.
Do this once when you set backups up, and again whenever you change the arrangement. An untested backup is a hypothesis, and the day you need it is the wrong day to test it.
Restoring for real
If you used a plugin, use its restore function. It handles file placement and URL rewriting together.
Manually, the order is: upload and extract the files, import the database into an empty database, then update wp-config.php with the credentials for that database. If the site is going back to a different domain or path, run a proper search-and-replace afterwards using a tool that understands serialized data; a plain SQL replacement corrupts serialized rows.
When restoring after a compromise, update everything before putting the site back online. Restoring a clean copy and leaving the same outdated plugin in place invites the same automated scan to do the same thing again. Securing WordPress against vulnerabilities walks through the order.
A backup is only useful if the restore goes well. How to Restore a WordPress Site from Backup explains restoring the least that fixes the problem.
A site taking orders while the backup runs needs more care than a schedule. How to Back Up a Store That Takes Orders Continuously walks through what changes.