How to Take a Backup of a Website

What a website backup has to contain

A website backup is the files plus the database, taken close enough together that they describe the same site. Files alone lose every post, product and setting; a database alone loses themes, uploads and plugin code. Both are needed, and both must be stored somewhere other than the server they protect.

Email, DNS records outside the account, and anything stored in a third-party service are separate. The email backup guide covers the mailboxes; DNS zones are in the cPanel archive but not in a plugin backup.

Take a full account backup in cPanel

The fastest complete copy is the account backup: one archive with files, databases, mail and settings. It is also the one people forget to download off the server.

1. Log in to cPanel, open Files, then Backup.
2. Choose Download a Full Account Backup, and leave the destination as the home directory. Do not choose a folder inside public_html, or the archive becomes publicly reachable.
3. Wait for the completion email, then download the archive over SFTP or from File Manager.
4. Delete the copy left on the server once the download is verified. A backup sitting on the same disk protects you from nothing.
5. Label the file with the date and the domain, and keep it with any note about what changed that day.

The archive restores by replacing the account, which makes it a poor tool for recovering one page. For that, use a plugin restore or copy the single file back. The click-by-click version is in the cPanel full backup guide.

Method 2: files over SFTP and the database from phpMyAdmin

This is the manual method and the one to know when a plugin is unavailable. Use SFTP rather than plain FTP, and take the database first so the files you download match the data they render.

1. In FileZilla, connect with SFTP on port 22 using the hosting username and password, then open public_html.
2. Select every file and folder and choose Download. On a large site, download wp-content in a second pass so a dropped connection does not restart everything.
3. In cPanel, open phpMyAdmin, select the site's database, then Export.
4. Choose Custom, select all tables, pick SQL, and tick Add DROP TABLE and IF NOT EXISTS. Compression is worth it for a database over a few hundred megabytes.
5. Download the .sql file, and check that its size is plausible rather than a few kilobytes.

The database export must come from phpMyAdmin or the command line, not from the file manager, because the data lives in the database server rather than in your home directory. The full export walkthrough is in the phpMyAdmin export guide.

Method 3: automate WordPress with a plugin

A backup plugin is the right answer for a site that changes weekly, because the schedule outlives your good intentions. Configure four things and leave it alone.

1. Install one backup plugin only. Two plugins writing archives to the same storage is how restores get confused.
2. Choose remote storage: Google Drive, Dropbox or S3-compatible object storage, not the hosting account.
3. Set the schedule to weekly, with the database daily if the site takes orders or comments.
4. Set retention to keep four or five copies, and add an email alert for failed runs.
5. Run one manual backup now, download it, and confirm the archive opens.

Exclusions are where plugin backups go wrong. If uploads are excluded to save space, a restore brings back a site with broken images. Check the file list once, not on the day you need it.

Method 4: host-managed backups and their limits

Most hosts keep their own snapshots, often daily, restorable from the panel. They are excellent for undoing a bad update and unreliable as your only archive.

• Retention is short: often seven to thirty days, which does not cover a problem you notice in month three.
• Restores are usually whole-account, so you cannot pull back one page or one order.
• The copy sits on infrastructure you do not control, and a billing lapse can remove access to it.
• Restores may need a support ticket, which is a fine trade in an emergency and a poor one at 2 a.m. on a launch night.

Ask three questions before you rely on them: how many days are kept, can a single file be restored, and is a copy stored outside the data centre that runs the site. WebJi® managed backup options are on the server backup solutions page, and they are quoted by email before payment.

Restore order: files first, then the database

Restore the files, then import the database, then fix anything that names the old environment. Doing it in the other order leaves you importing into a site that does not exist yet.

1. Create a staging subdomain or a folder copy, and restore there first. Never test a restore on the live site.
2. Upload the files to the new location, keeping the same structure, and restore the .htaccess and wp-config.php if they were not in the archive.
3. Create an empty database, import the .sql file through phpMyAdmin, and update the credentials in wp-config.php to the new database.
4. If the URL changed, run a search and replace on the database for the old domain, then update the site URL in Settings.
5. Load the site, log in, open a page with an image, and place a test order or submit the contact form. That is the pass condition.

Only after the staging copy works should you repeat the same steps on the live site, and only during a quiet hour with the old files kept in place until the new ones load.

How often to back up, and how many copies to keep

Match the frequency to how much content you would accept losing, and keep more than one copy in more than one place.

Two copies on different media and one off site is the shape of the 3-2-1 rule, and it applies to a five-page site as much as to a store. A second copy on the same disk is not a second copy.

Backup mistakes that only appear on restore day

Most failed recoveries are not corrupted archives. They are archives that never contained what the owner assumed.

• Files without the database, or the database without uploads: the site loads and every image, product or post is missing.
• Backups stored only on the hosting account, which disappear with the account.
• A schedule that stopped months ago, because nobody read the failure email.
• An archive taken during a migration, when half the files were already on the new server.
• A password-protected archive whose password is in nobody's password manager.
• No named owner, so the task quietly moves to whoever notices.

One restore test a quarter catches all six. Put it on a calendar with the name of the person who runs it, and keep the result in the same note as the archive list.