cPanel can produce a complete copy of your hosting account, files, databases, email accounts with their messages, DNS zone, cron jobs and settings, in a single archive. It is the most thorough backup available to you, and the least convenient to run regularly, because it is one large file you download by hand.
That combination makes it the right tool for specific moments rather than for routine protection. This covers when to use it, how to restore, and why your host's own backups are not a substitute for having your own.
Full backup or partial
In cPanel, open Backup. Two kinds are offered.
A full account backup covers everything on the account. It cannot be restored through cPanel by you. It is intended for moving an account to another server, or for handing to support to restore. It is the archive you want before something risky, and the one to hand a client who is leaving.
Partial backups cover one thing at a time: the home directory, a single database, email forwarders, filters. These you can restore yourself, directly in cPanel, which makes them the practical choice for recovering from a specific mistake.
For most purposes you want both: a full backup before a risky change, and partial backups when you need to put one thing back.
Taking a full backup
Choose Download a Full Account Backup, pick Home Directory as the destination, and start it. cPanel builds the archive in the background and emails you when it is ready, which on a large account can take a while.
Then download it and move it off the server. This is the step that gets skipped, and skipping it removes most of the value: an archive sitting in your home directory is lost along with everything else if the account is compromised or the disk fails. It also counts against your disk quota, so leaving several there can push the account over its limit and break the site in ways that look unrelated.
Restoring
Partial backups restore from the same Backup screen. Choose the file and upload it; cPanel puts the contents back.
Restoring the home directory replaces files. It does not delete files that were added since the backup was taken, so a compromised site restored this way can keep the injected file that caused the problem. When restoring after a compromise, this matters: the cleaner approach is to remove the site directory first and then restore.
Restoring a database imports over the existing one. Where possible, restore into an empty database rather than over a live one, then point the application at it once you have confirmed the contents.
A full account backup is restored by support, not by you. Open a ticket and say what you need put back; restoring an entire account over a working one is not something to trigger casually.
Restoring one file
Most recovery is not a disaster. It is one file overwritten by mistake.
You do not need to restore anything for that. Download the backup archive to your own machine, open it, find the file, and upload just that file. Restoring a whole home directory to recover one theme file will also revert everything else changed since the backup, which turns a small problem into a larger one.
Where cPanel backups fit
They are not a backup strategy on their own, because they depend on you remembering. A protection scheme that requires a human to do something monthly is a scheme that lapses quietly.
Use them as the deliberate snapshot before a risky change, and run something automatic alongside for routine protection: an application-level backup plugin pushing to remote storage, on a schedule, with retention long enough to reach back past a problem discovered late. Managing WordPress backups goes over that side, including how long to keep copies.
Your host's backups are not yours
Hosting providers keep their own backups, and they exist for infrastructure recovery. Their retention is chosen around that purpose, not around your needs, and they are not a service you should plan to depend on for restoring a file you deleted last Tuesday.
Ask what is actually available if you want to know. Do not assume, and do not let it replace a copy you control.
Test a restore before you need one
This is the step that turns the arrangement from a hope into a fact, and almost nobody does it.
Take a backup, then restore it somewhere that is not your live site; a subdomain or a staging install. Look at the result properly: does the homepage render, is recent content present, do images load, does the admin area work?
You are checking for specific failures that are common and invisible until tested: an archive missing the uploads folder because it exceeded a size limit, a database export truncated by a timeout, a file set that restored without its database.
Fifteen minutes now. The alternative is discovering which kind of backup you have on the day it matters.