CloudStick is a server control panel for developers and agencies that lets you manage cloud servers on AWS, DigitalOcean, Vultr, Linode, and Hetzner without using the command line. Plans start at $9/month — the Basic plan covers 1 server with unlimited websites; Pro at $19/month and Business at $49/month cover unlimited servers.

Will features I pay for ever get moved to a higher plan?

No. CloudStick is committed to keeping all features you currently pay for within your existing plan. New features may be added to higher tiers, but existing plan features will never be removed or require a forced upgrade.

What happens to my servers if I cancel CloudStick?

Your servers remain fully operational after cancellation. CloudStick does not host your servers — it manages them. If you cancel, you lose access to the CloudStick dashboard, but your servers continue running on your cloud provider.

Is there a free trial for CloudStick?

Yes. CloudStick offers a 7-day free trial on all paid plans with no credit card required. You can explore every feature and upgrade, downgrade, or cancel at any time during or after the trial.

BACKUPS

June 24, 2026

How to Restore a Server from a Backup After a Crash

11 min read

CloudStick Team

DevOps Engineer

Share this article

Server Restore Guide

Assess the Damage Before You Restore

The instinct after a crash is to restore immediately. Resist it. A premature restore to the same broken environment will fail or leave you right back where you started. Take 5–10 minutes to understand what actually failed before touching anything.

The three categories of failure each require a different restore path: (1) application-level failure (bad deploy, corrupted upload, accidental database drop), (2) OS-level failure (corrupted filesystem, failed update, kernel panic), (3) hardware/provider failure (disk failure, datacenter outage, provider-side issue). Only categories 1 and 2 are recoverable by restoring to the same server — category 3 requires provisioning a new server and restoring to it.

WARNING

If the crash was caused by a ransomware or malware attack, do NOT attempt to restore to a running system without first rebuilding the OS from scratch. Restoring data to a compromised environment reinfects the restore.

Choose the Right Restore Method

The restore method depends on what you backed up and what you need to recover:

File-level restore — extract a tar archive and overwrite specific files or directories. Fastest for targeted recovery (wrong files deleted, corrupted config).
Database restore — import a mysqldump SQL file. For database-level incidents (table dropped, bad migration).
Full server snapshot restore — restore a full disk snapshot (available from your cloud provider). For OS-level failures where the entire system needs to roll back.
New server + restore — provision a fresh server, install the stack, then restore data. Required for hardware failure or provider-level loss.

Restoring Files from a tar Archive

# Download backup from S3 (if offsite)
aws s3 cp s3://my-backups/site-backup-20260624.tar.gz /tmp/
# List the archive contents before extracting
tar -tzf /tmp/site-backup-20260624.tar.gz | head -30
# Extract to a staging directory first
mkdir /tmp/restore-staging
tar -xzf /tmp/site-backup-20260624.tar.gz -C /tmp/restore-staging
# Restore specific site directory
rsync -avz /tmp/restore-staging/var/www/mysite/ /var/www/mysite/
# Fix ownership after restore
chown -R www-data:www-data /var/www/mysite/

Always extract to a staging directory first so you can inspect the contents before overwriting live files. The rsync approach is safer than cp -r because it preserves permissions and lets you do a dry-run with --dry-run first.

Restoring the Database

# For WordPress: update wp-config.php DB credentials first if needed
# Then drop the broken database and recreate it
mysql -u root -p -e "DROP DATABASE my_db; CREATE DATABASE my_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
# Import the backup
gunzip -c /tmp/my_db-20260624.sql.gz | mysql -u root -p my_db
# Verify row counts on critical tables
mysql -u root -p my_db -e "SELECT COUNT(*) FROM wp_posts; SELECT COUNT(*) FROM wp_users;"

Post-Restore Verification Checklist

Never declare a restore complete until you have verified the site actually works:

HTTP 200 response on the home page and at least two inner pages
Login to the CMS or application works
A recent piece of content exists (confirms database restore point is recent enough)
Image uploads and static assets load
SSL certificate is valid and HTTPS redirects correctly
No critical errors in /var/log/nginx/error.log or the application log
Cron jobs are running (check crontab -l for the web user)

Restoring via CloudStick Dashboard

CloudStick stores backup archives in managed offsite storage accessible from the Backups section of your server panel. To restore, navigate to the server, open Backups, and select the archived backup you want to restore from. For database-specific restores, the Database Backups section lets you download a specific backup file by date and time to your local machine, then import it manually.

If you need to restore to a new server after a hardware failure, the process is: (1) connect a new server to CloudStick, (2) install the same stack, (3) create the databases and sites, (4) restore files and databases from the archived backups. The CloudStick agent installs automatically on the new server, preserving all dashboard management capabilities.