How to Manually Restore a WordPress Backup via SSH on Hostinger

Your hPanel backup restoration timed out at 78%, or you pulled down an off-site archive that’s way too big for a web interface to swallow. Restoring a broken WordPress site manually over SSH takes under five minutes once you know the exact command sequence.

I hit this exact issue last week when a botched WooCommerce upgrade trashed a client’s database. The web file manager choked on a 3.4GB wp-content directory, and phpMyAdmin flat-out refused to touch an 800MB SQL dump. Here is the step-by-step terminal workflow I use on Hostinger to extract files cleanly, pipe SQL dumps straight into MySQL with WP-CLI, fix permissions, and get everything back online fast.

Step 1: Prep SSH Access and Locate Your Backup Files

Before running anything in your terminal, make sure SSH is actually turned on. Shared and Cloud plans on Hostinger have SSH disabled by default until you flip the switch.

Jump into hPanel, go to Advanced > SSH Access, and toggle the connection switch to Enabled. Grab the connection details listed on that screen:

• SSH IP / Host: Your server IP address (e.g., 185.199.110.153 or ssh.hostinger.com)
• SSH Port: Hostinger uses custom port 65002 instead of the default port 22
• SSH Username: Your account identifier (e.g., u123456789)
• SSH Password: Your main hosting password or your uploaded SSH key

Connect from your local terminal using the custom port:

ssh -p 65002 u123456789@185.199.110.153

Once you’re in, navigate to your root folder. By default, your live site lives inside domains/yourdomain.com/public_html. Put your backup archive (usually a .zip or .tar.gz) and your raw database dump (backup.sql or backup.sql.gz) into the folder just above public_html or in a staging folder.

If your backup is sitting on an external server or S3 bucket, pull it down directly over SSH with wget or curl so you don’t waste time uploading it from your local machine:

cd ~/domains/yourdomain.com
wget https://my-offsite-storage.com/backups/site-backup-2025-05.tar.gz
wget https://my-offsite-storage.com/backups/db-backup-2025-05.sql.gz

Step 2: Clean Out the Broken WordPress Directory

Never extract a backup right on top of a corrupted WordPress install. Leftover plugin files, orphaned scripts, or malware will stick around and break things immediately.

Before deleting anything, check your current files and verify your disk space with df -h. Then move the broken site to a temporary folder or wipe the directory clean.

cd ~/domains/yourdomain.com
# Move broken install out of the way rather than instantly deleting
mv public_html public_html_broken
mkdir public_html

If you’re tight on disk quota and there’s nothing salvageable in there anyway, just clear the contents:

cd ~/domains/yourdomain.com/public_html
rm -rf * .htaccess

If you hit missing credentials or need to verify your database connection later, check our guide on fixing database connection errors on Hostinger.

Step 3: Extract WordPress Files and Assets

With an empty public_html directory ready, extract your archive. For .tar.gz files, run standard tar extraction:

tar -xzvf ~/domains/yourdomain.com/site-backup-2025-05.tar.gz -C ~/domains/yourdomain.com/public_html/

If your backup is a .zip archive (like exports from UpdraftPlus, Duplicator, or cPanel), use unzip with the quiet flag -q so your terminal doesn’t lag while printing tens of thousands of lines:

unzip -q ~/domains/yourdomain.com/site-backup-2025-05.zip -d ~/domains/yourdomain.com/public_html/

Sometimes archives wrap everything in a nested folder (like public_html/wordpress/ or public_html/my-backup/). If that happens, move the files up one level so WordPress sits directly in public_html:

cd ~/domains/yourdomain.com/public_html
mv wordpress/* ./
mv wordpress/.* ./
rmdir wordpress

Double-check that core files like index.php and wp-config.php, along with wp-content, wp-admin, and wp-includes, sit directly inside public_html.

Step 4: Check Database Credentials in wp-config.php

Your restored wp-config.php might still have credentials pointing to an old host, a local Docker setup, or a deleted database user. Hostinger needs the database name, username, and password to match what’s currently in your hPanel MySQL section.

Open up wp-config.php with nano:

nano ~/domains/yourdomain.com/public_html/wp-config.php

Find these constants and make sure they match your current Hostinger database setup:

// ** MySQL settings - You can get this info from your web host ** //
define( 'DB_NAME', 'u123456789_wpdb' );
define( 'DB_USER', 'u123456789_wpusr' );
define( 'DB_PASSWORD', 'YourSuperSecretPasswordHere123!' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

Don’t skip the table prefix. If your SQL dump uses wp_ but wp-config.php says wp_staging_, WordPress will show a blank install screen instead of your actual content. Scroll down in wp-config.php to verify:

$table_prefix = 'wp_';

Hit Ctrl + O and Enter to save in nano, then Ctrl + X to close.

Step 5: Drop Old Tables and Import the Database via MySQL CLI

Importing an SQL dump into a database that already has tables will trigger primary key conflicts and duplicate rows. We need to drop existing tables first, then stream the SQL file directly into MySQL.

CLI imports are lightning-fast and never time out like phpMyAdmin. For deep dives on dealing with tricky database imports, see our guide on importing large WordPress databases via SSH.

Hostinger comes with WP-CLI pre-installed, so resetting and importing takes just two commands:

cd ~/domains/yourdomain.com/public_html
# Wipe existing database tables safely
wp db reset --yes # Import uncompressed SQL dump
wp db import ~/domains/yourdomain.com/db-backup-2025-05.sql

If your database dump is compressed as .sql.gz, pipe it straight into the standard MySQL command-line client without decompressing it first:

gunzip < ~/domains/yourdomain.com/db-backup-2025-05.sql.gz | mysql -u u123456789_wpusr -p'YourSuperSecretPasswordHere123!' -h localhost u123456789_wpdb

Remember: there’s no space between -p and your password when passing it inline. If you’d rather not leave passwords in your bash history, omit the password flag value and type it at the prompt:

mysql -u u123456789_wpusr -p u123456789_wpdb < ~/domains/yourdomain.com/db-backup-2025-05.sql

Step 6: Update Site URLs and Run Search-Replace with WP-CLI

If this backup came from a staging site, a local domain (like mysite.local), or an old HTTP URL, your site will redirect visitors or break assets. Never use a raw find-and-replace in a text editor on a WordPress SQL file—it breaks PHP serialized arrays and corrupts your widgets and theme settings.

Use WP-CLI’s search-replace command to safely unpack, update, and re-serialize the strings:

cd ~/domains/yourdomain.com/public_html
wp search-replace 'https://staging.yourdomain.com' 'https://yourdomain.com' --all-tables --precise

Want to see what will change before actually modifying rows? Add --dry-run:

wp search-replace 'https://staging.yourdomain.com' 'https://yourdomain.com' --all-tables --dry-run

If you manage multiple environments regularly, check out how to manage a WordPress staging site on Hostinger without doing manual database surgery every time.

Step 7: Fix Linux File Permissions and Clear LiteSpeed Cache

Extracting archives over SSH as your master user can leave ownership or file permissions out of whack. Hostinger’s web server expects directories set to 755 and files set to 644.

Run these two find commands from inside public_html:

cd ~/domains/yourdomain.com/public_html # Set folder permissions to 755
find . -type d -exec chmod 755 {} + # Set file permissions to 644
find . -type f -exec chmod 644 {} + # Secure wp-config.php with tighter 600 or 640 permissions
chmod 640 wp-config.php

Hostinger runs LiteSpeed Web Server. Residual object cache files and LiteSpeed page cache will keep serving old redirects or broken styling until you wipe them. Clear both with WP-CLI:

# Flush WordPress internal object cache
wp cache flush # Remove static LiteSpeed cache files if present
rm -rf ~/domains/yourdomain.com/public_html/wp-content/lscache/*

Gotchas I Encountered (And How to Fix Them)

Manual restores rarely go 100% smoothly on the first attempt. Here are the three most common roadblocks I run into on Hostinger and how to solve them.

1. MySQL Server Has Gone Away (Error 2006)

If your database contains massive WooCommerce logs or bloated Elementor post revisions, the MySQL CLI can drop the connection with ERROR 2006 (HY000) at line 842: MySQL server has gone away. This means the SQL packet exceeded the server’s default packet limit.

Pass --max_allowed_packet directly to your import command to bypass it:

mysql --max_allowed_packet=512M -u u123456789_wpusr -p u123456789_wpdb < ~/domains/yourdomain.com/db-backup-2025-05.sql

2. Disk Inode / Quota Exhaustion During Extraction

Hostinger enforces hard caps on both total disk storage (GB) and Inodes (file count). If your extraction aborts midway with tar: write error: No space left on device, you’ve hit your disk or inode ceiling.

Check where you stand with:

df -h
du -sh ~/domains/yourdomain.com/*

Delete your compressed archive (site-backup-2025-05.tar.gz) as soon as you extract it, and clear out old logs like wp-content/debug.log to free up working space before retrying.

3. PHP Memory Limit Exhaustion on WP-CLI

If running wp search-replace or wp cache flush throws a fatal error about memory exhaustion (Fatal error: Allowed memory size of X bytes exhausted), the CLI is running under default restricted memory limits.

Override the memory limit directly in the command:

php -d memory_limit=512M $(which wp) search-replace 'https://oldurl.com' 'https://newurl.com' --all-tables

For more details on connection parameters and SSH keys, see the official Hostinger SSH documentation.

Frequently Asked Questions

Can I restore a WordPress backup if I only have the wp-content folder?

Yes. Drop a fresh copy of WordPress core files into public_html, replace the default wp-content folder with your backed-up version, import your database dump, and configure wp-config.php. WordPress core contains no site-specific user data.

Why does my site show a 403 Forbidden error after SSH restore?

A 403 Forbidden error almost always boils down to bad directory permissions or a missing index.php / .htaccess file. Make sure your public_html folder and all directories inside are 755 and files are 644.

How do I verify the database imported completely?

Run wp db query “SELECT count(*) FROM wp_posts;” or wp db size –tables over SSH. If the post count matches your original site and your core tables (wp_options, wp_users, wp_posts) have populated rows, the

Next Steps for Your Restored Site

With your files restored, database tables imported, and caches cleared, open an incognito window and hit /wp-login.php. Test an image upload in the Media Library right away to confirm file permissions and ownership are working properly.

To avoid having to run manual restores under pressure in the future, set up an automated backup workflow. Read our full guide on how to automate WordPress backups with WP-CLI and Cron on Hostinger to push scheduled snapshots off-site automatically.