Web hosting crisis migration, server disaster recovery, and backup restoration¶

+---------------------------------------------------------------------------------+
|                       WEB HOSTING OUTAGE TRIAGE MATRIX                          |
+---------------------------------------------------------------------------------+
| LEVEL 1: ADMINISTRATIVE ACCESS ACTIVE (SERVER ONLINE OR PARTIALLY ONLINE)       |
| - Symptoms: HTTP 500 errors, database connection dropouts, extreme throttling. |
| - Status: SSH, SFTP, or web hosting control panel (cPanel/Plesk) accessible.    |
| - Action: Execute immediate live extraction of SQL database and core files.    |
+---------------------------------------------------------------------------------+
| LEVEL 2: ACCOUNT SUSPENDED OR BILLING LOCKOUT                                   |
| - Symptoms: Default host "Account Suspended" landing page; control panel locked.|
| - Status: Server online, but customer portal credentials disabled.              |
| - Action: File emergency billing appeal while restoring from latest off-site   |
|   backup onto secondary cloud infrastructure immediately.                       |
+---------------------------------------------------------------------------------+
| LEVEL 3: CATASTROPHIC HARDWARE / DATACENTER DESTRUCTION                         |
| - Symptoms: Complete network timeout, server unresponsive, host status offline. |
| - Status: Physical server destroyed (fire, water damage, storage array crash). |
| - Action: Immediate bare-metal restore from off-site archives to new provider.  |
+---------------------------------------------------------------------------------+
| LEVEL 4: MALWARE / WEBSHELL INFECTION                                           |
| - Symptoms: Site defaced, blacklisted by Google Safe Browsing, phishing injected|
| - Status: File system compromised; database may contain injected malicious JS.  |
| - Action: Quarantined migration. Do not blindly copy infected webroot files.    |
+---------------------------------------------------------------------------------+

+---------------------------------------------------------------------------------+
|                     COMMAND LINE EXTRACTION (SSH TERMINAL)                      |
+---------------------------------------------------------------------------------+
| STEP 1: EXPORT AND COMPRESS MYSQL / MARIADB DATABASE                            |
| # Run mysqldump with single-transaction to prevent table locking on live sites: |
| mysqldump -u db_user -p --single-transaction --quick --skip-lock-tables \       |
|   db_name | gzip -9 > /tmp/emergency_db_backup.sql.gz                           |
|                                                                                 |
| STEP 2: EXPORT POSTGRESQL DATABASE (IF APPLICABLE)                              |
| # Run pg_dump in custom archive format with parallel compression:               |
| pg_dump -U db_user -F c -b -v -f /tmp/emergency_pg_backup.dump db_name          |
|                                                                                 |
| STEP 3: ARCHIVE APPLICATION ASSETS AND MEDIA                                    |
| # Compress the public web directory, excluding log files and cache caches:      |
| tar --exclude='./cache' --exclude='./var/cache' --exclude='./tmp' \             |
|   -czvf /tmp/emergency_files.tar.gz -C /var/www/html .                          |
|                                                                                 |
| STEP 4: OFFLOAD ARCHIVES DIRECTLY TO AN INDEPENDENT LOCAL MACHINE               |
| # On your local computer, pull the compressed archives over secure copy:        |
| scp -P 22 user@compromised-server.com:/tmp/emergency_*.gz ./local_recovery/     |
+---------------------------------------------------------------------------------+

Target Stack Installation Checklist (Ubuntu 24.04 LTS):
=============================================================================
# Update system packages:
sudo apt update && sudo apt upgrade -y

# Install web server (Nginx or Apache2):
sudo apt install -y nginx

# Install database engine (MariaDB Server):
sudo apt install -y mariadb-server

# Secure database installation:
sudo mysql_secure_installation

# Install PHP runtime and essential extensions (adjust version as needed):
sudo apt install -y php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd \
  php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl php8.3-bcmath

# Verify service statuses:
sudo systemctl enable --now nginx mariadb php8.3-fpm
=============================================================================

+---------------------------------------------------------------------------------+
|                       DATABASE INITIALIZATION AND IMPORT                        |
+---------------------------------------------------------------------------------+
| STEP 1: LOG INTO MYSQL AS ROOT                                                  |
| sudo mysql -u root                                                              |
|                                                                                 |
| STEP 2: CREATE FRESH DATABASE AND ISOLATED SERVICE USER                         |
| CREATE DATABASE target_database_name                                            |
|   CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;                             |
| CREATE USER 'target_service_user'@'localhost'                                   |
|   IDENTIFIED BY 'GenerateExceedinglyComplexPasswordString64Chars';               |
| GRANT ALL PRIVILEGES ON target_database_name.*                                  |
|   TO 'target_service_user'@'localhost';                                         |
| FLUSH PRIVILEGES;                                                               |
| EXIT;                                                                           |
|                                                                                 |
| STEP 3: STREAM RESTORATION FROM GZIPPED ARCHIVE                                 |
| zcat /path/to/emergency_db_backup.sql.gz | \                                    |
|   mysql -u target_service_user -p target_database_name                           |
+---------------------------------------------------------------------------------+

File Ownership and Security Hardening Commands:
=============================================================================
# Set web server daemon ownership (www-data on Debian/Ubuntu):
sudo chown -R www-data:www-data /var/www/site_root

# Restrict directory permissions to 755 (rwxr-xr-x):
sudo find /var/www/site_root -type d -exec chmod 755 {} +

# Restrict standard file permissions to 644 (rw-r--r--):
sudo find /var/www/site_root -type f -exec chmod 644 {} +

# Protect sensitive configuration files containing database credentials:
# (WordPress wp-config.php, Laravel .env, Drupal settings.php):
sudo chmod 600 /var/www/site_root/wp-config.php
sudo chmod 600 /var/www/site_root/.env
=============================================================================

+-------------------+--------------------+----------------------------------------+
| RECORD TYPE       | NAME               | TARGET VALUE                           |
+-------------------+--------------------+----------------------------------------+
| A Record          | @ (root domain)    | [New Target Server IPv4 Address]       |
+-------------------+--------------------+----------------------------------------+
| AAAA Record       | @ (root domain)    | [New Target Server IPv6 Address]       |
+-------------------+--------------------+----------------------------------------+
| CNAME Record      | www                | yourdomain.com                         |
+-------------------+--------------------+----------------------------------------+
| Time To Live      | TTL Setting        | 300 seconds (5 minutes)                |
+-------------------+--------------------+----------------------------------------+

Emergency DNS Strategies:
=============================================================================
1. PRE-PLANNED CUTOVER (TTL ALREADY REDUCED):
   - If TTL was previously configured to 300 seconds (5 minutes), updating
     the A record propagates globally within 5 to 10 minutes.

2. UNPLANNED OUTAGE WITH HIGH TTL (e.g., 86400 SECONDS / 24 HOURS):
   - When TTL is set to 86400 seconds, internet service providers will cache
     the dead server IP for up to 24 hours. Changing the A record at your
     registrar will take a full day to reach all global visitors.
   - EMERGENCY BYPASS SOLUTION: Switch nameservers to a reverse proxy service
     (such as Cloudflare).
   - Because Cloudflare takes authoritative control of edge proxy routing
     immediately upon nameserver delegation, enabling the proxy status
     instantly routes web traffic to your new server IP address, bypassing
     stale local ISP DNS caches worldwide within minutes.
=============================================================================

Automated TLS Provisioning Protocol:
=============================================================================
# Install Certbot and the Nginx plugin:
sudo apt install -y certbot python3-certbot-nginx

# Request and configure automated certificates:
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com \
  --non-interactive --agree-tos -m admin@yourdomain.com \
  --redirect

# Verify automated renewal timer:
sudo systemctl status certbot.timer

# Perform a dry-run test renewal:
sudo certbot renew --dry-run
=============================================================================

Email Infrastructure Preservation Checklist:
=============================================================================
1. PRESERVE THIRD-PARTY MX RECORDS:
   - Ensure MX records continue pointing to your dedicated email provider
     (e.g., Google Workspace, Microsoft 365, Fastmail, ProtonMail).
   - Example Google Workspace MX configuration:
     - Priority 1: ASPMX.L.GOOGLE.COM
     - Priority 5: ALT1.ASPMX.L.GOOGLE.COM
     - Priority 5: ALT2.ASPMX.L.GOOGLE.COM
   - Never leave MX pointing to `mail.yourdomain.com` on the new server unless
     you are operating an active, configured Postfix/Dovecot mail transfer agent.

2. UPDATE SENDER POLICY FRAMEWORK (SPF) TXT RECORDS:
   - If your website sends transactional emails (order receipts, password
     resets, contact form alerts) directly from the new server, add the new
     server IPv4 address to your SPF record.
   - Example record:
     `v=spf1 ip4:NEW_SERVER_IP include:_spf.google.com ~all`
   - Failure to authorize the new server IP will cause transactional emails
     to land in customer spam folders or bounce entirely.

3. RE-ESTABLISH DKIM SIGNING:
   - If using transactional SMTP relays (SendGrid, Postmark, Amazon SES,
     Mailgun), confirm that DomainKeys Identified Mail (DKIM) CNAME records
     are mirrored precisely in the active DNS manager.
=============================================================================

Quarantined Restoration Sequence:
=============================================================================
1. REBUILD CODEBASE FROM TRUSTED REPOSITORIES:
   - Never copy core executable binaries from an infected server.
   - Deploy clean application core files directly from vendor repositories:
     - For WordPress: Download a fresh zip archive from wordpress.org.
     - For custom applications: Pull clean release tags from private GitHub,
       GitLab, or Bitbucket repositories.
     - Reinstall clean plugin and theme packages fresh from official catalogs.

2. SANITIZE USER UPLOADS AND MEDIA DIRECTORIES:
   - Hackers routinely hide malicious `.php` webshell scripts disguised as
     `.jpg` or `.png` files inside media directories (such as `wp-content/uploads/`).
   - Run strict recursive shell checks on your downloaded media folder:
     # Locate and delete any PHP script hiding in media directories:
     find /path/to/uploads -type f -name "*.php*" -exec rm -vf {} +
     # Remove hidden executable script files:
     find /path/to/uploads -type f \( -name "*.phtml" -o -name "*.py" \
       -o -name "*.sh" -o -name "*.cgi" \) -exec rm -vf {} +

3. INSPECT THE DATABASE FOR INJECTED JAVASCRIPT:
   - Search your SQL dump file for common injection vectors before importing:
     grep -E "(<script|eval\(|base64_decode|gzinflate)" emergency_db_backup.sql
   - Clean any injected admin accounts or unauthorized redirect scripts.
=============================================================================

Resilient Backup Pipeline Specification:
=============================================================================
3: Maintain at least THREE copies of all production data
   (Live production server, local automated backup, and off-site cloud storage).
2: Store backups across TWO distinct storage media formats
   (Block storage snapshots and compressed object storage archives).
1: Maintain at least ONE backup copy at an independent third-party provider
   (e.g., Backblaze B2, Amazon S3 Glacier, Wasabi, or Google Cloud Storage).
   Never store backups on the same hosting account or hypervisor cluster as
   the production server.
=============================================================================