Most people trust the backups their shared host says it keeps. Then they open cPanel's Backup Wizard and find there is no Google Drive option. A cPanel automatic backup to Google Drive needs a workaround. Even then it can fail when disk space runs out, the host kills long-running processes, or Google authorization expires.
Quick answer: cPanel can't send a full backup straight to Google Drive. You have two options:
- Schedule full cPanel backups to your home directory or a remote server, then push them to Drive with rclone.
- Use cron and rclone to upload website files and MySQL dumps directly.
Either way, keep the copies outside your hosting account and test that you can restore them.
I run HeadsNTail on Namecheap shared cPanel hosting. Years ago, I learned why an independent backup matters while recovering a client site: the host had backups, but restoring a full account required a support ticket. Since then, I keep a separate copy of every site I manage, outside the hosting account.
Why your hosting provider's backup isn't enough
Most shared hosts keep some backups, but the retention period, restore options and guarantees depend on the plan. A backup listed in your hosting dashboard isn't necessarily one you can download whenever you need it.
There are two separate problems:
- You can't restore a full-account backup from cPanel itself. That runs through WHM, so on shared hosting you usually need the provider's support.
- Backups stored only inside the account can be out of reach. If the account is suspended, compromised or locked, you may lose access to them exactly when you need them.
The usual answer is the 3-2-1 backup rule: keep three copies of your data, on two different storage types or locations, with at least one copy off the original server. For a small business website, use the live site, an independent off-site copy, and a second separately controlled copy. That is far safer than relying on the hosting account alone.
What a full cPanel backup contains
A full cPanel backup can include:
- Website files under
public_htmland the other files you own in the home directory. - MySQL databases associated with the account.
- Email accounts and mail data.
- Email forwarders and filters.
- Account configuration needed for restoration.
The Backup Wizard offers these full-backup destinations:
- Home Directory
- Remote FTP Server
- Remote FTP Server (passive mode)
- Secure Copy (SCP)
Google Drive isn't on that list.
For partial backups, cPanel offers:
- A home-directory archive (
.tar.gz) - Per-database MySQL downloads (
.sql.gz) - Email forwarder and filter backups
Disk quota is the other catch. A full backup is built inside your account before it goes anywhere. If the account is nearly full, generation can fail because cPanel can't write the archive. See the official cPanel Backup Wizard documentation.
Which method should you use?
- You have Terminal or SSH: use Method 2 (cron + rclone). It's what I use, because I control where files go, how often they're copied and how long they're kept. It can also push full cPanel archives to Drive.
- You have Cron Jobs but no SSH: use Method 1. Namecheap's script only needs cron and PHP. Point it at a remote server you control.
- Neither works reliably on your plan: use Method 3.
Before configuring anything, check that you can:
- Generate a manual backup successfully.
- Open cPanel's Cron Jobs page.
- Upload files to a remote server, or run a command-line tool your host allows.
Don't schedule anything until the manual backup works.
Method 1: Schedule full cPanel backups with Namecheap's PHP script
Namecheap publishes a PHP script, fullbackup.php, that asks cPanel to generate a full account backup. It's the closest option to the native cPanel backup process. The script and its settings are in the official Namecheap automatic backup instructions.
Configure fullbackup.php
Copy the latest script from Namecheap's article and edit the values at the top:
-
$cpaneluserand$cpaneluserpass: your cPanel login. Namecheap warns that special characters such as&or^in the password can break the script. -
$theme: must match your cPanel theme. It'sjupiteron most current accounts. -
$ftpserver:localhostsaves the backup back into the same account. A remote hostname sends it off-site. -
$ftpusernameand$ftppassword: login for the destination server. -
$ftpport: the script defaults to21098, Namecheap's SSH port. Most other SSH servers use22. -
$ftpdirectory: destination folder. It must already exist, or the backup fails. -
$domain: your cPanel server hostname.
Two things the variable names hide:
-
The transfer method is SCP, not FTP. Despite the
ftpnames, the current version sends the request withdest=scp. The destination must accept SSH/SCP logins. -
The default destination is not off-site. With
localhost, the archive lands in~/backupson the same hosting account. To get it to Google Drive, combine this with the rclonemovestep in Method 2.
Save the script in your home directory, outside public_html:
/home/youraccount/fullbackup.php
It contains your cPanel password, so restrict it to your own user:
chmod 600 "$HOME/fullbackup.php"
The script logs in with your password over the cPanel port. If you turn on two-factor authentication for cPanel, test it again; password-only logins like this may stop working.
Schedule the backup for Monday at 02:00
Open cPanel > Advanced > Cron Jobs and add Namecheap's documented schedule:
0 2 * * 1 /usr/local/bin/php /home/youraccount/fullbackup.php
Replace youraccount with your cPanel username and confirm the PHP CLI path with your host. If you'd rather not hand-write cron syntax, the cron job generator builds the line for you.
This requests a backup every Monday at 02:00, server time. The archive is generated in the background and can finish much later. A successful cron run only proves the request was sent, not that a complete archive reached the destination. Check the destination after the first run, and keep monitoring it.
Exclude existing backups from new ones
If old archives sit in your home directory, every new full backup includes all the previous ones. On an account of a few GB, that quickly eats the quota.
Create or edit cpbackup-exclude.conf in your home directory:
/home/youraccount/cpbackup-exclude.conf
Add one entry per line. Paths are relative to your home directory, and * excludes a folder's contents:
backups/*
private-backups/*
backup-*.tar.gz
This file applies to full account backups. It does not change what goes into a Home Directory partial backup. Only exclude folders you've confirmed hold disposable backup copies, not live application files or customer uploads.
On Namecheap's Stellar Plus and Stellar Business plans, the AutoBackup cPanel plugin already keeps daily, weekly and monthly full backups you can restore or download. Check your plan before building a second system.
Method 2: cPanel automatic backup to Google Drive with rclone
rclone can upload to Google Drive without root access, as long as your host allows user-installed executables and outbound connections.
This main script creates a website-level backup: the folders you choose plus database dumps. It doesn't include email accounts, DNS zones or other account-level settings. For those, use the full-archive step further down.
Install rclone without root
Open cPanel Terminal or connect over SSH, then check your architecture:
uname -m
x86_64 means the amd64 build; aarch64 means arm64. For amd64, download rclone straight into a private ~/bin folder:
mkdir -p "$HOME/bin" && chmod 700 "$HOME/bin"
cd "$HOME"
curl -fsSLO https://downloads.rclone.org/rclone-current-linux-amd64.zip
unzip -j -o rclone-current-linux-amd64.zip '*/rclone' -d "$HOME/bin"
rm rclone-current-linux-amd64.zip
chmod 700 "$HOME/bin/rclone"
"$HOME/bin/rclone" version
unzip -j pulls just the rclone binary out of the versioned folder inside the zip.
If curl can't reach the site, take the fallback route:
- Download the same zip from rclone.org/downloads on your PC.
- Extract it and upload the
rclonefile to~/binwith File Manager. - Run the last two commands above.
If rclone version fails with "cannot execute binary file" or a permission error, you either picked the wrong architecture or your host blocks custom executables.
Connect Google Drive
Start the configuration:
"$HOME/bin/rclone" config
Create a new remote, name it gdrive, and choose Google Drive as the storage type.
For unattended backups, create your own Google OAuth client ID by following the rclone Google Drive documentation. rclone's shared Google client ID is being retired and will stop working during 2026. A remote that relies on it will break without warning.
When rclone asks whether to use a web browser on this machine, answer n. It then prints an rclone authorize command to run on a computer that has a browser.
Run that command on your Windows PC (with rclone installed there). It looks like this:
rclone authorize "drive"
Copy the exact command your server printed. With your own client ID, it includes the ID and secret. Sign in to Google, approve access, and paste the token back into the server's prompt.
The token in ~/.config/rclone/rclone.conf gives full access to your Drive. Treat that file like a password.
Test the connection:
"$HOME/bin/rclone" lsd gdrive:
If your Drive folders are listed, authorization works.
Create the automatic backup script
Create a private MySQL client file at /home/youraccount/.my.cnf:
[client]
user=your_database_user
password="your_database_password"
host=localhost
Keep the quotes around the password; they stop characters like # from being read as a comment. On cPanel, the database user must be added to every database you list below, in MySQL Databases > Add User to Database.
Protect the file:
chmod 600 "$HOME/.my.cnf"
Create /home/youraccount/databases.txt with one database per line:
youraccount_website
youraccount_store
Then create backup.sh in your home directory:
#!/usr/bin/env bash
set -euo pipefail
umask 077
STAMP="$(date +%F-%H%M%S)"
ROOT="$HOME/private-backups"
RCLONE="$HOME/bin/rclone"
REMOTE="gdrive:cpanel-backups"
mkdir -p "$ROOT"
# Archives left behind by failed uploads: keep them 7 days, then remove so they don't fill the quota
find "$ROOT" -maxdepth 1 -name 'site-*.tar.gz' -mtime +7 -delete
WORK="$(mktemp -d "$ROOT/work.XXXXXXXX")"
trap 'rm -rf "$WORK"' EXIT
mkdir -p "$WORK/sql"
while IFS= read -r DB || [[ -n "$DB" ]]; do
[[ -z "$DB" || "$DB" == \#* ]] && continue
if [[ ! "$DB" =~ ^[A-Za-z0-9_]+$ ]]; then
echo "Invalid database name: $DB" >&2
exit 1
fi
mysqldump \
--defaults-extra-file="$HOME/.my.cnf" \
--single-transaction \
--quick \
--no-tablespaces \
--default-character-set=utf8mb4 \
"$DB" > "$WORK/sql/$DB.sql"
# mysqldump writes this line only when the dump finished
if [[ "$(tail -n 1 "$WORK/sql/$DB.sql")" != *"Dump completed"* ]]; then
echo "Incomplete dump: $DB" >&2
exit 1
fi
done < "$HOME/databases.txt"
ARCHIVE="$ROOT/site-$STAMP.tar.gz"
tar -czf "$ARCHIVE" \
-C "$HOME" \
--exclude='public_html/wp-content/cache' \
--exclude='public_html/storage/logs' \
public_html \
-C "$WORK" sql
"$RCLONE" copyto "$ARCHIVE" \
"$REMOTE/$STAMP/site-$STAMP.tar.gz" \
--bwlimit 1M
rm -f "$ARCHIVE"
# Retention: only reached after a successful upload, because set -e stops the script earlier on any failure
"$RCLONE" delete "$REMOTE" --min-age 30d --rmdirs
What the script does:
- Dumps each database into a temporary folder.
- Archives the dumps together with
public_html. - Uploads the archive to a dated folder in Google Drive. rclone checks the size and checksum after upload.
- Deletes the local copy only after the upload succeeds. If an upload fails, the archive stays in
private-backupsfor up to 7 days so you can investigate.
Notes from running this on real accounts:
- Retention only runs after a successful upload. That ordering matters. If the job breaks for a month, the old backups in Drive are still there.
- Test retention before trusting it. Do a dry run first:
"$HOME/bin/rclone" delete gdrive:cpanel-backups --min-age 30d --rmdirs --dry-run
Keep cpanel-backups dedicated to these archives. Drive moves deleted files to the trash, where they still count against your storage until the trash is emptied.
-
Laravel and other frameworks: if your application code lives outside
public_html(as it should), add those directories to thetarline. Otherwise you'll save the public entry point without the application itself. -
--single-transactiongives a consistent dump for InnoDB tables only. MyISAM tables can still change during the dump. -
Stored procedures and events: if you use them, add
--routinesand--events. On shared hosting these can need privileges your user doesn't have, so check the dump for errors after adding them.
Schedule it safely
Make the script executable and run it once by hand:
chmod 700 "$HOME/backup.sh"
bash "$HOME/backup.sh"
Confirm the dated folder and archive appear in Google Drive. Then add a daily cron job at 02:00:
0 2 * * * /usr/bin/flock -n /home/youraccount/.backup.lock /bin/bash /home/youraccount/backup.sh >> /home/youraccount/backup.log 2>&1
Replace the account name and confirm the paths to flock and bash with command -v flock bash.
flock -n skips a run if the previous one is still going. The log gives you evidence when something breaks. Don't send the output to /dev/null: a backup job that fails silently is worse than no job, because you think you're covered. For more cron diagnostics on cPanel, see Laravel schedule:run not working on cPanel.
Send full cPanel archives to Google Drive too
The script above skips email accounts and account settings. If you need those, have cPanel build a full archive in your home directory, then let rclone move it to Drive.
First, add the exclusions from Method 1 to cpbackup-exclude.conf. Otherwise each full archive contains private-backups and the previous full archives.
Then add two cron jobs. The first asks cPanel for a full backup on Monday at 01:00:
0 1 * * 1 /usr/bin/uapi Backup fullbackup_to_homedir email=you@example.com >> /home/youraccount/fullbackup.log 2>&1
cPanel writes a file named like backup-MM.DD.YYYY_HH-mm-ss_youraccount.tar.gz in your home directory and emails you when it finishes. Check the uapi path with command -v uapi.
The second job moves finished archives to Drive three hours later:
0 4 * * 1 /usr/bin/flock -n /home/youraccount/.fullbackup.lock /home/youraccount/bin/rclone move /home/youraccount gdrive:cpanel-full --include "/backup-*.tar.gz" --max-depth 1 --min-age 30m >> /home/youraccount/fullbackup.log 2>&1
How the flags work:
-
--include "/backup-*.tar.gz"with--max-depth 1matches only archives in the top of your home folder. -
--min-age 30mskips any file modified in the last 30 minutes, so an archive still being written is left alone until a later run. -
movedeletes the local copy only after a verified upload, which frees the quota again.
You need enough free space for one full archive at a time.
Why I keep backups small
For my own sites, the backup job creates MySQL dumps, archives the website files and uploads the result to separate storage. One of my typical archives is about 40 MB, and the job finishes in under two minutes. That's my setup, not a speed to expect on every shared host.
The biggest improvement came from exclusions. Before I excluded backup folders, caches and old logs, the archive size tripled within a month. Just don't exclude customer uploads, database files or application storage to make the number look better.
Method 3: Back up cPanel without Terminal or SSH
Some shared plans disable Terminal and SSH, but still give you Cron Jobs, File Manager, phpMyAdmin and the Backup Wizard. Start with what you have:
- Cron Jobs works: Method 1 still runs, because it only needs cron and PHP. Point it at a remote SSH server or a small VPS you control. That server can then sync to Google Drive with rclone.
-
No cron either: download a home-directory archive from Backup Wizard, and export each database in phpMyAdmin (or download the
.sql.gzfrom the Backup page). Store both on a trusted machine.
A scheduled PHP database-export script is possible if your host allows cron PHP. The exporter must handle SQL escaping, large tables and database objects correctly. A script that just prints table rows is not a database backup.
If your plan includes a managed tool such as Namecheap's AutoBackup, check whether its retention and download options meet your needs before building anything yourself. For the folder layout of a Laravel app on shared hosting, see the Laravel deployment checklist for cPanel.
Why automatic cPanel backups fail and how to confirm the cause
Backup stops when disk usage reaches the account quota
Symptom: Backup generation fails, or stops before producing a complete archive.
Check: Open cPanel > Disk Usage and look at free space. A full backup needs room for the whole compressed archive while it's being built. Expect that to be a large share of your current usage.
Fix:
- Remove temporary files and old copies you've already verified elsewhere.
- Exclude backup folders as shown in Method 1.
- Move archives off the account as soon as they're done.
Never delete your only valid backup to make room for a new one.
mysqldump fails with a PROCESS privilege error
Symptom: The log shows Access denied; you need (at least one of) the PROCESS privilege(s) for this operation when dumping tablespaces.
Cause: Since MySQL 8.0.21, mysqldump needs the PROCESS privilege to dump tablespace information. Shared hosting users don't have it.
Fix: Add --no-tablespaces, as in the script above. Shared-hosting sites don't need tablespace information in their dumps.
Script fails with $'\r': command not found
Cause: You edited backup.sh or databases.txt on Windows, and the file kept Windows line endings. Bash reads the stray \r, and database names stop matching the validation pattern.
Fix:
sed -i 's/\r$//' "$HOME/backup.sh" "$HOME/databases.txt"
Or set your editor to save with LF line endings.
Google Drive authorization stops working
Symptom: rclone reports an OAuth, invalid_grant or token error.
Check:
"$HOME/bin/rclone" lsd gdrive:
Fix: If this fails, run "$HOME/bin/rclone" config reconnect gdrive: and re-authorize from your PC as before.
If the error comes back after about a week, your OAuth app is probably still in Testing mode. rclone's documentation notes that testing grants can expire after seven days. Publish the app (set it to production) in Google Cloud so the token stays valid for unattended runs.
rclone is killed by the hosting provider
Symptom: The script stops during compression or upload, sometimes with no error at all.
Check: Read backup.log, and look for resource-limit notices in cPanel. On CloudLinux hosts, check Resource Usage.
Fix: Test with lower bandwidth and a single transfer:
"$HOME/bin/rclone" copy \
"$HOME/private-backups" \
"gdrive:backup-test" \
--transfers 1 \
--bwlimit 1M
This is only a transfer test, not a replacement for the dated archive script. Delete backup-test afterwards.
No rclone flag gets around CPU, memory, process or execution-time limits. For large sites, a remote machine that pulls backups over SSH is often more reliable than compressing inside a restricted shared account.
The cron job runs twice or overlaps
Symptom: Two backup processes run at once, filling disk space or hitting resource limits.
Check: Look for duplicate entries in Cron Jobs, and for running processes with ps -u "$USER" -f.
Fix: Use flock, as shown earlier. If your host doesn't provide it, use an atomic lock directory (mkdir succeeds for only one process) and handle stale locks left by crashed runs.
Remote backup folder doesn't exist
Symptom: The backup request is accepted, but nothing arrives at the destination.
Check: Confirm the remote hostname, login, port and destination path. For Namecheap's script, remember the transfer is SCP, so the destination must accept SSH logins.
Fix: Create the destination directory before the first scheduled run.
Test the restore, not just the backup
A backup that has never been restored is still an assumption.
Once a month, I download the latest archive and restore the site locally with XAMPP. The first time I did this, I found that a database export was empty: the cron job had run before the database user had the permissions it needed, and nothing warned me. That's why I don't treat a successful upload as proof of a usable backup.
Download the latest rclone archive from Google Drive and list its contents. Windows 10 and 11 include tar, so this works in PowerShell or Command Prompt:
tar -tzf "site-2026-10-20-020000.tar.gz"
Replace the filename with your archive. You should see public_html/... and sql/... entries.
Extract it:
mkdir C:\restore-test
tar -xzf "site-2026-10-20-020000.tar.gz" -C C:\restore-test
Create a test database in XAMPP. The default XAMPP root user has no password, so just press Enter at the prompt:
C:\xampp\mysql\bin\mysql.exe -u root -p -e "CREATE DATABASE testwebsite CHARACTER SET utf8mb4"
Import the dump. Run this in Command Prompt, not PowerShell, because PowerShell doesn't support < redirection:
C:\xampp\mysql\bin\mysql.exe -u root -p --default-character-set=utf8mb4 testwebsite < "C:\restore-test\sql\youraccount_website.sql"
Next:
- Copy the application files into your local XAMPP project.
- Point its database settings at
testwebsite. - Open the site.
- Check the homepage, a login, a few important records and uploaded media.
If any of these fail, your backup is incomplete, and now you know before you need it.
To restore on live cPanel by hand, upload the files with File Manager, import the SQL in phpMyAdmin, and update database credentials in the app's config.
A full cPanel archive works differently. You can extract it to pull out individual files or the database dumps in its mysql folder. A complete account restore, though, goes through your hosting provider or an authorized WHM restore.
If you need help checking backup coverage or a failed restore, contact HeadsNTail.
FAQ
Does cPanel back up my website to Google Drive automatically?
No. cPanel has no Google Drive destination, and any automatic server backups are set by your host's plan, not by cPanel itself. Check what your host keeps and whether you can download it. For copies in Drive, use rclone with cron, as in Method 2.
Can I restore a full cPanel backup myself?
Not as a one-click restore from the standard cPanel interface; full-account restores go through WHM or your hosting provider. You can extract the archive yourself and restore website files and databases manually with File Manager and phpMyAdmin.
Is Google Drive safe for website backups?
It's a reasonable off-site destination, but your archives contain database credentials and possibly customer data. Turn on two-factor authentication for the Google account. Keep the rclone token private. For sensitive sites, encrypt the archives before upload with rclone's crypt remote.
How often should a small business website be backed up?
Base the schedule on how much data you could afford to lose:
- Booking or e-commerce sites: at least daily database backups.
- Mostly static sites: weekly backups are often enough.
Whatever the schedule, test a restore regularly.
Start with one successful manual backup. Prove you can restore it. Only then switch on the cron schedule and automatic retention.
Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.
Top comments (0)