How to Back Up WordPress Manually via SSH

Backup plugins are convenient, but they have limits. Some fail silently. Some produce corrupted archives you only discover when you actually need to restore. Some can’t handle large databases or run into PHP timeout limits on shared hosting. And if WordPress itself is broken, a plugin that runs inside WordPress can’t help you.

Knowing how to back up WordPress manually through the command line means you can create a reliable backup regardless of what state your site is in. It’s also the fastest method for large sites, since you’re working directly with the server rather than going through PHP.

A manual backup consists of two parts: your MySQL database (all your posts, pages, settings, and user data) and your WordPress files (themes, plugins, uploads, and configuration). Here’s how to grab both.

Connect to your server via SSH#

You need command-line access to your web server. SSH (Secure Shell) gives you that.

On Linux or macOS, open a terminal and connect:

ssh username@your-server-ip

Replace username with your server account username and your-server-ip with the server’s IP address or hostname. If your host uses a non-standard SSH port, add -p followed by the port number:

ssh -p 2222 username@your-server-ip

On Windows, you have a few options:

• Windows Terminal or PowerShell support SSH natively on Windows 10 and later. The syntax is identical to Linux.
• PuTTY is a standalone SSH client if you prefer a GUI. Enter your server’s address, port, and username in the session configuration.

SSH key authentication is more secure than passwords. If your hosting provider supports it (and most do), upload your public key to the server and connect without typing a password each time. This also makes scripting automated backups easier.

Once connected, you’ll have a shell prompt on your server. Everything from here happens on the server itself.

Step 1: Back up your MySQL database#

Your WordPress database contains everything that isn’t a file: posts, pages, comments, user accounts, plugin settings, widget configurations, and options. Losing the database means losing your content even if you have all the files.

Find your database credentials

Your database name, username, and password are stored in wp-config.php in your WordPress root directory. If you don’t know them off the top of your head, pull them from the file:

grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST" /path/to/wordpress/wp-config.php

This outputs something like:

define( 'DB_NAME', 'wordpress_db' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'your_password_here' );
define( 'DB_HOST', 'localhost' );

Create the database dump

Use mysqldump to export the entire database to a SQL file:

mysqldump -u wp_user -p wordpress_db > ~/backup_2026-02-27.sql

You’ll be prompted for the password. Replace wp_user and wordpress_db with your actual credentials.

The ~/ puts the backup file in your home directory, which is outside the web root. Never store database backups inside your public web directory. A SQL dump contains your entire database, including user accounts and hashed passwords. If it’s accessible via a web browser, anyone can download it.

Verify the dump

Check that the file was created and has a reasonable size:

ls -lh ~/backup_2026-02-27.sql

A typical WordPress database dump ranges from a few megabytes to several hundred megabytes depending on your content volume. If the file is 0 bytes or suspiciously small, the dump failed. Check for error messages and verify your credentials.

You can also confirm the dump ends properly:

tail -5 ~/backup_2026-02-27.sql

The last line of a valid mysqldump output should be something like -- Dump completed on 2026-02-27 . If it’s cut off mid-statement, the dump was interrupted (often by a timeout or disk space issue).

Compress the database dump

SQL files compress extremely well since they’re plain text:

gzip ~/backup_2026-02-27.sql

This creates backup_2026-02-27.sql.gz and removes the original uncompressed file. A 200MB SQL dump typically compresses to 20-30MB.

Step 2: Back up your WordPress files#

Your WordPress files include everything in the site’s root directory: the WordPress core, your wp-content folder (themes, plugins, uploads), wp-config.php , and any custom files like .htaccess .

Identify your WordPress root directory

This varies by hosting provider. Common locations:

• /home/username/public_html/
• /var/www/html/
• /home/username/www/
• /home/username/htdocs/

If you’re not sure, check with your hosting provider or look for the directory containing wp-config.php :

find /home -name "wp-config.php" -type f 2>/dev/null

Create a compressed archive

Navigate to the parent directory of your WordPress installation and create a tar archive:

cd /home/username/
tar -czvf ~/wordpress_backup_2026-02-27.tar.gz public_html/

Breaking down the flags:

• -c  creates a new archive
• -z  compresses it with gzip
• -v  shows progress (verbose output; skip this with  -czf  if you prefer a quiet operation)
• -f  specifies the output filename

The archive is saved to your home directory. Depending on how many uploads your site has (images, PDFs, videos), this can take anywhere from a few seconds to several minutes.

Check the archive

Verify the archive was created and looks right:

ls -lh ~/wordpress_backup_2026-02-27.tar.gz

To list the contents without extracting:

tar -tzf ~/wordpress_backup_2026-02-27.tar.gz | head -20

This shows the first 20 files in the archive so you can confirm it contains what you expect.

Step 3: Download the backup to your local machine#

The backup files are on your server, but a backup that only exists on the server it’s protecting isn’t much of a backup. Download both files to your local machine or another storage location.

Using SCP (command line)

From your local machine (not the server), run:

scp username@your-server-ip:~/backup_2026-02-27.sql.gz ./
scp username@your-server-ip:~/wordpress_backup_2026-02-27.tar.gz ./

This copies both files to your current local directory. If your host uses a non-standard SSH port:

scp -P 2222 username@your-server-ip:~/backup_2026-02-27.sql.gz ./

Using SFTP (GUI)

If you prefer a graphical interface:

1. Open an SFTP client like WinSCP (Windows), FileZilla (cross-platform), or Cyberduck (macOS)
2. Connect to your server using the same SSH credentials
3. Navigate to your home directory on the remote side
4. Drag the  .sql.gz  and  .tar.gz  files to a folder on your local machine

Clean up the server

Once you’ve confirmed the download completed successfully, remove the backup files from the server to free up disk space:

rm ~/backup_2026-02-27.sql.gz ~/wordpress_backup_2026-02-27.tar.gz

Restoring from a manual backup#

Backing up is only half the equation. Here’s how to restore if you need to.

Restore the database

Upload the SQL dump back to the server, decompress it, and import it:

gunzip backup_2026-02-27.sql.gz
mysql -u wp_user -p wordpress_db < backup_2026-02-27.sql

This overwrites the current database with the backup. Make sure you’re importing into the correct database.

Restore the files

Upload the tar archive and extract it:

cd /home/username/
tar -xzvf wordpress_backup_2026-02-27.tar.gz

This extracts the files and overwrites existing ones. Your file permissions should be preserved from when the archive was created.

After restoring both the database and files, load your site in a browser to verify everything is working. Clear any caching (both server-side and browser) to ensure you’re seeing the restored version.

Automating manual backups with a script#

Once you’re comfortable with the manual process, you can script it to run on a schedule. Here’s a basic backup script:

#!/bin/bash

# Configuration
DB_USER="wp_user"
DB_NAME="wordpress_db"
WP_DIR="/home/username/public_html"
BACKUP_DIR="/home/username/backups"
DATE=$(date +%Y-%m-%d)

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

# Database backup
mysqldump -u "$DB_USER" -p"$DB_PASSWORD" "$DB_NAME" | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

# Files backup
tar -czf "$BACKUP_DIR/files_$DATE.tar.gz" -C "$(dirname $WP_DIR)" "$(basename $WP_DIR)"

# Delete backups older than 14 days
find "$BACKUP_DIR" -name "*.gz" -mtime +14 -delete

echo "Backup completed: $DATE"

Save this as backup.sh , make it executable with chmod +x backup.sh , and add it to cron for automatic daily execution:

crontab -e

Add this line to run the backup at 3 AM daily:

0 3 * * * /home/username/backup.sh

Store the database password in an environment variable or a MySQL option file ( ~/.my.cnf ) rather than hardcoding it in the script. A .my.cnf file looks like this:

[mysqldump]
user=wp_user
password=your_password_here

Set permissions so only your user can read it:

chmod 600 ~/.my.cnf

With this in place, mysqldump reads credentials from the file automatically and you can remove the -u and -p flags from the script.

Where to store your backups#

A backup on the same server as your website doesn’t protect you if the server fails. Store copies in at least one other location:

• Your local machine (what we covered in step 3)
• Cloud storage (S3, Google Cloud Storage, Backblaze B2) for offsite redundancy
• A second server if you have one available

The idea is simple: if any single location is lost, you can still restore. Two copies in two different physical locations is the minimum for real protection.

Even if your hosting provider includes automated backups (and they should), keeping your own independent copy means you’re never dependent on a single provider to recover your site. Your data, your responsibility.

Using your backup for site migration#

The same backup files used for disaster recovery work for migrating WordPress to a new server. Upload the file archive to the new server, extract it, import the database dump, update wp-config.php with the new database credentials, and update the site URL in the database if the domain is changing:

mysql -u new_user -p new_database -e "UPDATE wp_options SET option_value='https://newdomain.com' WHERE option_name IN ('siteurl', 'home');"

A manual backup gives you a portable, self-contained copy of your entire WordPress site that works anywhere MySQL and PHP are available.

Check out the WordPress backup documentation for additional reference.

Try Hostney web hosting free for 14 days. Every plan includes automated daily backups with 14-day retention, plus full SSH access for manual backups whenever you need them.