How to Backup Your Website Using SSH: 4 Methods for Linux Servers (Updated 2026)

 Last Updated: June 2026 — All commands verified on cPanel/WHM servers (AlmaLinux 8, CentOS 7) and standalone Linux servers (Ubuntu 22.04, Debian 12).

Backing up your website through SSH is one of the most reliable and flexible methods available to any Linux system administrator or web hosting professional. Unlike control panel-based backups, SSH gives you full control over what gets backed up, where it goes, and when it runs — with no GUI overhead or timeouts for large sites. 

Backup Your Website Using SSH

 

This guide covers four practical methods: a quick tar file backup, a full cPanel account backup using pkgacct, a MySQL database dump, and how to automate everything with a cron job.

1. Why Use SSH for Website Backups?

Most shared hosting control panels offer one-click backup tools, but they have real limitations:

  • They often time out on large websites (over 5 GB).
  • They provide no scheduling flexibility without a paid upgrade.
  • They keep backups on the same server as your site — useless if the server fails.
  • You cannot automate or customize what gets included.

SSH-based backups solve all of these. They run in the background without timeouts, can be scheduled to run automatically, and you can pipe the output directly to a remote server or cloud storage.

 Prerequisites: You need SSH access to your server (root or sudo user), and PuTTY (Windows) or a terminal (Linux/macOS) to connect.

2. Method 1: Backup Website Files with tar

The tar command is the standard Linux tool for creating compressed file archives. It works on any Linux server regardless of whether cPanel is installed.

Step 1 — Connect to your server via SSH

ssh root@your-server-ip

Step 2 — Create a backup directory

mkdir -p /home/backups

Step 3 — Create the compressed archive

tar -czf /home/backups/website-backup-$(date +%Y-%m-%d).tar.gz /var/www/html/

What each flag means:

  • -c — Create a new archive
  • -z — Compress with gzip
  • -f — Specify the output filename
  • $(date +%Y-%m-%d) — Automatically inserts today's date in the filename (e.g., website-backup-2026-06-01.tar.gz)
⚠️ Note: Replace /var/www/html/ with your actual website root path. On cPanel servers this is typically /home/username/public_html/.

Step 4 — Verify the backup was created

ls -lh /home/backups/

You should see your .tar.gz file with its size. To verify the archive is not corrupted:

tar -tzf /home/backups/website-backup-2026-06-01.tar.gz | head -20

3. Method 2: Full cPanel Account Backup with pkgacct

If your server runs cPanel/WHM, the pkgacct script is the most complete backup method available. It creates a single archive containing everything for a hosting account: website files, all databases, email accounts, email filters, DNS zone records, cron jobs, and cPanel settings.

✅ When to use this: Use pkgacct when you need a complete account backup before migrating to a new server, before major changes, or when a client requests a full download of their account.

Step 1 — Run pkgacct as root

/scripts/pkgacct username

Replace username with the actual cPanel account username. The script will run and display progress. For a large account this may take several minutes.

When complete, the backup file is created at:

/home/cpmove-username.tar.gz

Step 2 — Make the backup downloadable by the user

To allow the website owner to download their own backup through the browser, move it to their public directory and set correct permissions:

chmod 644 /home/cpmove-username.tar.gz
mv /home/cpmove-username.tar.gz /home/username/public_html/cpmove-username.tar.gz

The user can then download it from: https://theirdomain.com/cpmove-username.tar.gz

⚠️ Security reminder: Delete this file from public_html immediately after the user downloads it. A backup archive left in a public directory is a serious security risk — it exposes all website files and database credentials to anyone who knows the URL.

pkgacct Useful Options

Command Description
/scripts/pkgacct username Full account backup (default)
/scripts/pkgacct --skiphomedir username Backup without home directory files (databases + config only)
/scripts/pkgacct --skipdbs username Backup without databases (files only)
/scripts/pkgacct username /backup/ Save the archive to a custom directory instead of /home/

4. Method 3: Backup the MySQL/MariaDB Database

Website files alone are not a complete backup. Your database contains all dynamic content — posts, users, orders, settings. Always back it up separately in addition to your files.

Backup a single database

mysqldump -u root -p database_name > /home/backups/db-backup-$(date +%Y-%m-%d).sql

You will be prompted for the MySQL root password. Replace database_name with your actual database name.

Backup all databases at once

mysqldump -u root -p --all-databases > /home/backups/all-databases-$(date +%Y-%m-%d).sql

Compress the database dump immediately

mysqldump -u root -p database_name | gzip > /home/backups/db-backup-$(date +%Y-%m-%d).sql.gz

Piping directly to gzip saves disk space significantly — a 500 MB database dump often compresses down to 50–80 MB.

5. Method 4: Automated Backup Script with Cron

Manual backups get forgotten. The right approach is a shell script that backs up both files and database, then schedule it to run automatically every night.

Step 1 — Create the backup script

Create a new file at /usr/local/bin/website-backup.sh:

#!/bin/bash

# ── Configuration ──────────────────────────────
BACKUP_DIR="/home/backups"
WEBSITE_DIR="/home/username/public_html"
DB_NAME="your_database_name"
DB_USER="root"
DB_PASS="your_db_password"
KEEP_DAYS=7
DATE=$(date +%Y-%m-%d)
# ───────────────────────────────────────────────

# Create backup directory if it doesn't exist
mkdir -p "$BACKUP_DIR"

# 1. Backup website files
echo "Backing up website files..."
tar -czf "$BACKUP_DIR/files-$DATE.tar.gz" "$WEBSITE_DIR"

# 2. Backup database
echo "Backing up database..."
mysqldump -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" | gzip > "$BACKUP_DIR/db-$DATE.sql.gz"

# 3. Delete backups older than KEEP_DAYS
echo "Removing backups older than $KEEP_DAYS days..."
find "$BACKUP_DIR" -type f -mtime +$KEEP_DAYS -delete

echo "Backup completed successfully: $DATE"

Step 2 — Make the script executable

chmod +x /usr/local/bin/website-backup.sh

Step 3 — Test it manually first

/usr/local/bin/website-backup.sh

Check that files appear in /home/backups/:

ls -lh /home/backups/

Step 4 — Schedule with crontab

crontab -e

Add this line to run the backup every night at 2:00 AM:

0 2 * * * /usr/local/bin/website-backup.sh >> /var/log/website-backup.log 2>&1

The >> /var/log/website-backup.log 2>&1 part writes all output (including any errors) to a log file so you can check if backups are running successfully.

 Pro tip: The script includes automatic cleanup with find ... -mtime +7 -delete which removes backups older than 7 days. This prevents your disk from filling up over time. Adjust KEEP_DAYS to suit your retention policy.

6. How to Restore from a Backup

Restore website files from a tar archive

tar -xzf /home/backups/files-2026-06-01.tar.gz -C /

The -C / flag extracts the archive back to its original absolute path.

Restore a MySQL database

# First create the database if it doesn't exist
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS database_name;"

# Then import the dump
gunzip < /home/backups/db-2026-06-01.sql.gz | mysql -u root -p database_name

Restore a full cPanel account with pkgacct

/scripts/restorepkg /home/cpmove-username.tar.gz

7. Backup Best Practices

  • Follow the 3-2-1 rule: Keep 3 copies of your data, on 2 different storage types, with 1 copy offsite (cloud or remote server).
  • Never store backups on the same server as your website. If the server is hacked or fails, you lose both.
  • Test your restores. A backup you have never tested is a backup you cannot trust. Restore to a staging server at least once every few months.
  • Encrypt sensitive backups. If your backup contains customer data or database credentials, encrypt it with GPG before storing or transferring.
  • Monitor your backup logs. Check /var/log/website-backup.log weekly or set up an email alert in your cron job.
  • Define a retention policy. Daily backups for 7 days, weekly for 4 weeks, and monthly for 12 months is a common and solid policy.

Frequently Asked Questions

Q: What is the difference between pkgacct and a tar backup?

A tar backup copies raw files and directories. It is simple and portable but does not include databases, email accounts, DNS records, or cPanel configuration. The pkgacct script is cPanel-specific and creates a structured archive of everything belonging to a hosting account — files, databases, email, and settings — in a format that can be fully restored with /scripts/restorepkg.

Q: My website is very large (50GB+). Will tar time out?

No. When running through SSH, there is no web-based timeout. However, for very large sites it is better to run the command inside a screen or tmux session so it continues if your SSH connection drops:

screen -S backup
tar -czf /home/backups/website-backup.tar.gz /home/username/public_html/
# Press Ctrl+A then D to detach. The backup continues in the background.

Q: How do I copy my backup to a remote server?

Use scp or rsync to transfer the archive to another server:

scp /home/backups/website-backup-2026-06-01.tar.gz user@remote-server:/backups/

Q: How do I find the correct username for pkgacct?

In WHM, go to Account Information → List Accounts. The username is the short cPanel login name (usually 8 characters or less). Alternatively, from the command line: ls /var/cpanel/users/ lists all cPanel usernames on the server.

Q: Can I automate offsite backups to Amazon S3 or Google Cloud?

Yes. After creating the local archive, use the AWS CLI or rclone to upload it. For example, with rclone configured for S3:

rclone copy /home/backups/ s3:your-bucket-name/website-backups/ --min-age 1h

Summary

Backing up your website via SSH is fast, reliable, and fully automatable. Use tar for file-only backups on any Linux server, pkgacct for complete cPanel account backups, mysqldump for databases, and combine them all in a scheduled shell script for hands-free protection. Always verify your backups and store at least one copy off-server.

Have a question or need help adapting these scripts to your specific setup? Leave a comment below.

Comments