Table of Contents

1. How to Recognize a Compromised DigitalOcean Server
2. Do Not Immediately Delete the Malicious Files
3. Take a Snapshot of the Compromised Droplet
4. Check Your DigitalOcean Backups
5. Why You Should Not Immediately Restore the Existing Droplet
6. Create a New Droplet from the Suspected Clean Backup
7. Verify the Restored /var/www Directory
8. Identify Your Web Stack
9. Check Whether the Backup Itself Contains Malware
10. Check File Modification Dates
11. Inspect SSH Users and SSH Keys
12. Inspect SSH Login History
13. Inspect Cron Jobs
14. Inspect Systemd Services and Timers
15. Check Which Network Ports Are Open
16. Investigate FTP and SFTP Access
17. Check the Database
18. Identify the Initial Attack Vector
19. Do Not Assume One Website Was Responsible
20. Restore Websites from a Known-Clean Point
21. WordPress Recovery
22. Restore the Database Carefully
23. Rebuild Rather Than “Clean” When Possible
24. Create a Fresh, Hardened DigitalOcean Droplet
25. Use SSH Keys Instead of Password Authentication
26. Use a Non-Root Administrative User
27. Configure a DigitalOcean Cloud Firewall
28. Keep the Operating System Updated
29. Install Fail2Ban Where Appropriate
30. Protect Website File Permissions
31. Keep Databases Off the Public Internet
32. Rotate All Credentials After the Breach
33. Check Your DigitalOcean Account
34. Update Every CMS, Plugin and Theme
35. Scan the Recovered Websites
36. Keep the Compromised Droplet for Investigation
37. Convert an Important DigitalOcean Backup to a Snapshot
38. Put the Websites Back Online Only After Verification
39. Change DNS After Testing
40. Monitor the New Server After Migration
41. Improve the Architecture for Multiple Websites
42. Implement a Proper Backup Strategy
43. Follow the 3-2-1 Backup Principle
44. Common Mistakes to Avoid
45. Complete DigitalOcean Recovery Checklist
46. Recommended Recovery Architecture
47. What the Suspicious PHP Code Means
48. The Safest Overall Solution
49. Final Recommendations

DigitalOcean Server Hacked? Complete Guide to Recovering Your Websites

A hacked web server can be extremely stressful, particularly when several websites are hosted on the same DigitalOcean Droplet and the files suddenly disappear or are replaced with unfamiliar PHP files.

A common example is a server where /var/www/html previously contained multiple websites but suddenly contains heavily obfuscated PHP files with code using functions such as curl_exec(), eval()-style dynamic execution, base64_decode(), shell_exec(), INPUT_GET, or long sequences of randomly generated variable names.

The correct response is not to manually delete suspicious files and continue using the same server. The safer approach is to preserve the compromised environment, identify a known-clean backup, restore to a separate environment, validate the websites and databases, rotate credentials, investigate the entry point, and then move production to a clean and hardened server.

1. How to Recognize a Compromised DigitalOcean Server

A server may be compromised when you notice one or more of the following symptoms:

• Websites suddenly disappear.
• Files in /var/www/html are replaced by unknown files.
• PHP files contain highly obfuscated code.
• File names are random or unfamiliar.
• Website redirects appear unexpectedly.
• New administrator accounts appear in WordPress or another CMS.
• Unknown SSH keys are present.
• FTP/SFTP credentials stop working or appear to have been changed.
• Server CPU or bandwidth usage suddenly increases.
• New cron jobs or systemd services appear.
• Search engines report malware or hacked content.
• Database content has been modified.
• New PHP files appear inside upload directories.
• Multiple websites on the same server are affected simultaneously.

One particularly strong indicator is heavily obfuscated PHP code.

goto u0HHECunnL71;

$F5KKjNR8c_1L = range("\x7e", "\x20");

curl_init(...);
curl_exec(...);

Legitimate PHP applications can technically contain unusual code, but a combination of obfuscation, dynamic function generation, network fetching, request-parameter processing and runtime code execution is a major security warning.

When several independent websites are affected simultaneously, the problem is usually larger than a single hacked website.

2. Do Not Immediately Delete the Malicious Files

This is one of the most important rules during recovery.

Do not immediately:

Delete all suspicious PHP files
Reinstall PHP
Reinstall Apache/Nginx
Overwrite /var/www/html
Restore random website files
Run an automatic "malware cleaner"
Reboot repeatedly

Why?

Because the compromised server can contain evidence that helps determine:

• how the attacker entered;
• when the compromise happened;
• which account was compromised;
• whether SSH was accessed;
• whether FTP was abused;
• whether another website was the entry point;
• whether persistence was installed;
• whether database credentials were exposed.

You should preserve the original environment before making destructive changes.

3. Take a Snapshot of the Compromised Droplet

Before performing major changes, create a DigitalOcean snapshot of the current server.

Use a name such as:

COMPROMISED-DROPLET-2026-08-20

A snapshot serves as a forensic fallback and preserves the current state before recovery actions change the filesystem.

4. Check Your DigitalOcean Backups

The next step is to inspect the backups associated with the Droplet.

In the DigitalOcean Control Panel:

Droplets
→ Select your Droplet
→ Backups

Look for backup dates around the point when the compromise occurred.

August 20   ← compromised
August 19   ← possibly compromised
August 18   ← possibly compromised
August 17   ← potentially clean
August 16   ← potentially clean
August 15   ← potentially clean
August 14   ← potentially clean

Do not automatically select the newest backup. The objective is to locate a backup that was created before the compromise.

5. Why You Should Not Immediately Restore the Existing Droplet

Restoring an existing Droplet can replace its current state with the backup image. That can be appropriate when you know the backup is clean, but during a security incident it is safer to preserve the compromised system first.

Existing compromised Droplet
             ↓
      Preserve it
             ↓
Known-clean backup
             ↓
Create NEW Droplet
             ↓
Inspect and verify

This allows you to investigate the recovered environment without immediately destroying the compromised state.

6. Create a New Droplet from the Suspected Clean Backup

Once you identify a backup that predates the attack:

1. Open the original Droplet.
2. Go to Backups.
3. Locate the backup.
4. Use the option to create a new Droplet from that backup.
5. Give the new Droplet a temporary name.
6. Attach a new SSH key.
7. Do not change your production DNS yet.

                    Internet
                       |
                       |
             Existing DNS records
                       |
                       v
              OLD COMPROMISED SERVER
                       |
              Keep untouched
                       |
              ---------------------

              NEW RECOVERY SERVER
              Created from backup
                       |
                  Temporary IP

7. Verify the Restored /var/www Directory

After logging in to the recovery server, inspect the web directories.

sudo -i

ls -lah /var/www
ls -lah /var/www/html

Then inspect recent file timestamps:

find /var/www/html -type f \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort -r | head -100

You should determine whether:

• the original website files are present;
• all three websites are present;
• their directory structures look normal;
• suspicious PHP files exist;
• files were modified shortly before the backup.

8. Identify Your Web Stack

Before restoring applications, determine what the server was running.

php -v

nginx -v

apache2ctl -v

mysql --version

mariadb --version

Also inspect:

ls -lah /etc/nginx/sites-enabled/
ls -lah /etc/apache2/sites-enabled/

You may have a configuration such as:

Internet
   ↓
Nginx
   ↓
PHP-FPM
   ↓
Website
   ↓
MySQL/MariaDB

or:

Internet
   ↓
Apache
   ↓
PHP
   ↓
MySQL/MariaDB

9. Check Whether the Backup Itself Contains Malware

A backup is not automatically safe simply because it is older.

Look for PHP files:

find /var/www -type f \
\( -name "*.php" -o -name "*.phtml" -o -name "*.php5" \) -print

Search for common indicators:

grep -RniE \
"base64_decode|eval\(|gzinflate|str_rot13|assert\(|shell_exec|passthru|system\(|proc_open|popen\(|curl_exec" \
/var/www 2>/dev/null

This is only an initial screening method. A compromised server should not be declared clean based on one grep command.

10. Check File Modification Dates

File timestamps can help identify when the attack occurred.

find /var/www -type f -printf \
'%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort -r | head -200

You can also find files changed within a particular period:

find /var/www -type f -mtime -10 -ls

Look particularly for:

• Random PHP files
• Files in uploads directories
• Unexpected .php files
• New configuration files
• New .htaccess files
• Modified index.php
• Modified wp-config.php
• Modified framework bootstrap files

11. Inspect SSH Users and SSH Keys

One of the most important questions is: Did the attacker gain SSH access?

cat /etc/passwd

Show users with interactive shells:

awk -F: '$7 ~ /(bash|sh|zsh|fish)$/ {
print $1,$3,$6,$7
}' /etc/passwd

Inspect SSH keys:

find /root/.ssh /home \
-name authorized_keys \
-type f \
-exec sh -c \
'echo "===== $1 ====="; cat "$1"' _ {} \;

If you find an SSH key you do not recognize, assume the attacker may have server-level access.

12. Inspect SSH Login History

On Ubuntu/Debian systems, inspect authentication logs:

grep -iE \
"Accepted|Failed|Invalid|session opened" \
/var/log/auth.log | tail -200

last -a | head -50

lastlog

You are looking for:

• unknown IP addresses;
• successful logins you cannot explain;
• unexpected usernames;
• logins at unusual times;
• repeated failed attempts followed by a successful login.

13. Inspect Cron Jobs

Attackers commonly create scheduled jobs to restore malicious files after removal.

crontab -l

sudo crontab -l

ls -lah /etc/cron.d/
ls -lah /etc/cron.hourly/
ls -lah /etc/cron.daily/
ls -lah /etc/cron.weekly/

grep -Rni "" /etc/cron* 2>/dev/null

Look for commands that:

• download files;
• execute PHP;
• use curl;
• use wget;
• write to /var/www;
• execute scripts from /tmp;
• execute commands as root.

14. Inspect Systemd Services and Timers

Persistence does not have to use cron.

systemctl list-unit-files --state=enabled

systemctl list-timers --all

Investigate services you do not recognize:

systemctl status SERVICE_NAME

15. Check Which Network Ports Are Open

sudo ss -tulpn

Typical web server ports include:

22   SSH
80   HTTP
443  HTTPS

Investigate anything unexpected, such as:

21    FTP
3306  MySQL
6379  Redis
8080  custom application

16. Investigate FTP and SFTP Access

You mentioned having FTP access. Determine what service is running:

systemctl status vsftpd

systemctl status proftpd

ps aux | grep -Ei "ftp|vsftpd|proftpd"

If the server was using traditional FTP, migrate to SFTP or another encrypted transfer method.

17. Check the Database

Website recovery is incomplete if the database is compromised.

sudo mysql

SHOW DATABASES;

Check database users:

sudo mysql -e \
"SELECT User,Host,plugin FROM mysql.user;"

Look for:

• unknown users;
• unexpected hosts;
• databases that were not created by you;
• unexpected tables;
• modified administrator records.

18. Identify the Initial Attack Vector

Restoring the websites is only half the job. You also need to determine: How did the attacker get in?

Vulnerable WordPress plugin

An outdated plugin may contain an exploitable vulnerability.

Vulnerable theme

A commercial or custom theme can contain security issues or malicious code.

Compromised administrator account

An attacker may have obtained a CMS administrator password.

Exposed FTP credentials

Credentials may have been stolen or reused elsewhere.

SSH credential compromise

An attacker who obtains an SSH key or password may gain direct server access.

Vulnerable PHP application

Custom PHP applications can expose upload, command execution, SQL injection, file inclusion, or authentication vulnerabilities.

Outdated server software

Old PHP, Apache, Nginx, framework components or operating-system packages may expose known vulnerabilities.

Another website on the same Droplet

This is particularly important when multiple unrelated websites share one server. One vulnerable application may have provided the initial foothold and allowed the attacker to modify the other websites.

19. Do Not Assume One Website Was Responsible

Multiple sites on a single server share the same operating system and potentially the same permissions.

DigitalOcean Droplet
│
├── Website A
├── Website B
└── Website C

If Website A is compromised and PHP is running with excessive privileges, an attacker may potentially reach files belonging to Website B and Website C.

A stronger architecture can be:

Droplet 1 → Website A

Droplet 2 → Website B

Droplet 3 → Website C

Alternatively, use containers, separate service accounts and carefully designed permissions.

20. Restore Websites from a Known-Clean Point

Once the backup has been validated, restore the websites.

Do not automatically restore every server-level credential and configuration file from the compromised environment.

Separate the recovery into:

Website code
Website uploads
Database
Web server configuration
SSL configuration
Application configuration
Credentials
Operating-system configuration

Treat credentials and operating-system configuration as potentially compromised.

21. WordPress Recovery

For WordPress, the key components are generally:

WordPress core
wp-content/themes/
wp-content/plugins/
wp-content/uploads/
wp-config.php
Database

A safer approach is to restore WordPress core from a known-good version rather than trusting compromised core files.

Plugins and themes should be updated or replaced from their official sources where possible.

Be particularly careful with:

wp-content/uploads/

Attackers frequently attempt to place executable files in upload directories. Look for:

find wp-content/uploads -type f \
\( -name "*.php" -o -name "*.phtml" \)

Any unexpected executable PHP inside an uploads directory deserves immediate investigation.

22. Restore the Database Carefully

If the database backup predates the compromise, restore it separately.

Before putting the restored database into production:

• verify administrator accounts;
• inspect unexpected users;
• inspect suspicious content;
• review scheduled actions;
• inspect application settings;
• check for injected JavaScript or redirects.

23. Rebuild Rather Than “Clean” When Possible

Delete malware
Repair files
Remove persistence
Update packages
Change credentials
Continue using server

Fresh operating system
+
Known-good application files
+
Known-good databases
+
Fresh credentials
+
Fresh SSH keys
+
Fresh configuration

24. Create a Fresh, Hardened DigitalOcean Droplet

A hardened configuration should look like:

Internet
   |
   +---- HTTPS :443
   |
   +---- HTTP :80
   |
   +---- SSH :22
           |
        Restricted
        by firewall

Do not expose unnecessary ports.

25. Use SSH Keys Instead of Password Authentication

Create a new key:

ssh-keygen -t ed25519

Keep the private key secure. Never upload your private SSH key to the server. Only the public key should be installed in:

~/.ssh/authorized_keys

26. Use a Non-Root Administrative User

Create a dedicated sudo user:

sudo adduser deploy
sudo usermod -aG sudo deploy

Use the new administrative account for normal work and reserve root privileges for operations that actually require them.

27. Configure a DigitalOcean Cloud Firewall

At a basic level, a public web server normally needs:

HTTP   80
HTTPS  443
SSH    22

SSH should ideally be restricted to known administrative IP addresses or otherwise protected by an appropriate access strategy.

28. Keep the Operating System Updated

sudo apt update
sudo apt full-upgrade -y

Also regularly update:

• Linux packages
• PHP
• Nginx/Apache
• MySQL/MariaDB
• WordPress
• Plugins
• Themes
• Framework dependencies
• Composer packages
• Node packages

29. Install Fail2Ban Where Appropriate

Install:

sudo apt install fail2ban -y

Enable it:

sudo systemctl enable --now fail2ban

Then configure the jails appropriate to your services. Fail2Ban should complement—not replace—proper SSH authentication, firewall rules and patch management.

30. Protect Website File Permissions

The application should not have unrestricted write access to the entire server.

PHP process can write everywhere

Instead, use restrictive ownership and permissions appropriate to your application.

Application files → mostly read-only
Uploads → writable only where needed
Configuration → not publicly writable
Web server → no unnecessary system privileges

31. Keep Databases Off the Public Internet

If MySQL or MariaDB is only required by your application, there is generally no reason to expose it publicly.

0.0.0.0:3306

For a single-server setup:

Website
   |
localhost
   |
MySQL

32. Rotate All Credentials After the Breach

Change:

SSH passwords
SSH keys
SFTP credentials
FTP passwords
WordPress administrator passwords
Database passwords
SMTP passwords
API keys
Cloudflare API tokens
DigitalOcean API tokens
GitHub deploy keys
Payment gateway secrets
Third-party API credentials

If the old credential existed on the compromised server, assume it may have been exposed.

33. Check Your DigitalOcean Account

Review your DigitalOcean account for:

Unknown SSH keys
Unknown API tokens
Unexpected team members
Unexpected Droplets
Unexpected snapshots
Unexpected volumes
Unexpected firewall rules
Unexpected DNS changes

Delete or revoke anything you do not recognize.

34. Update Every CMS, Plugin and Theme

For WordPress

WordPress Core
Plugins
Themes
WooCommerce
Security plugins
Custom code

For Laravel/CodeIgniter or another PHP application

PHP
Composer packages
Framework
Third-party libraries
Custom authentication
File-upload handlers
Admin interfaces

Do not reinstall the same vulnerable component that caused the original compromise.

35. Scan the Recovered Websites

Search for dangerous PHP constructs:

grep -RniE \
"base64_decode|eval\(|gzinflate|shell_exec|passthru|system\(|assert\(|curl_exec" \
/var/www 2>/dev/null

Find recent files:

find /var/www -type f -mtime -10 -ls

Find PHP files in upload directories:

find /var/www -path "*/uploads/*" \
-type f \( -name "*.php" -o -name "*.phtml" \)

Then perform application-specific security scans. For WordPress, use a reputable malware/security scanner in addition to manual inspection.

36. Keep the Compromised Droplet for Investigation

Do not immediately delete the original Droplet.

Original compromised Droplet
+
Compromised snapshot
+
Clean recovery environment

Keep these until:

• all websites work;
• all databases are verified;
• credentials are rotated;
• DNS has been moved;
• monitoring is working;
• no suspicious activity remains.

37. Convert an Important DigitalOcean Backup to a Snapshot

If you find a backup that is definitely clean and want to preserve it longer, convert it into a longer-retention recovery point where appropriate.

Clean Backup
      ↓
Convert to Snapshot
      ↓
Long-term recovery point

38. Put the Websites Back Online Only After Verification

New Server
   |
   +-- Website 1
   +-- Website 2
   +-- Website 3
   |
   +-- Database
   +-- SSL
   +-- Firewall
   +-- Monitoring

Test each domain using the new server's IP before switching DNS.

Verify:

Homepage
Admin
Login
Forms
Contact forms
Email
Images
Uploads
Database queries
Payments
APIs
Cron jobs
SSL
Redirects
404 pages
robots.txt
sitemap.xml

39. Change DNS After Testing

OLD SERVER
    ↓
DNS record
    ↓
NEW SERVER

Update A, AAAA, and CNAME records as applicable.

After DNS has propagated, monitor the new server closely.

40. Monitor the New Server After Migration

For the first several days, monitor:

CPU
RAM
Disk usage
Network traffic
Authentication failures
Unexpected files
Web server logs
PHP errors
Database activity

Useful commands include:

top

df -h

free -h

sudo ss -tulpn

41. Improve the Architecture for Multiple Websites

Hosting several unrelated websites on one Droplet is convenient, but it increases the blast radius of a compromise.

For higher security, consider:

Option 1
Separate Droplet per important website

Option 2
Containerized applications

Option 3
Separate Linux users and PHP-FPM pools

Option 4
Separate servers for high-risk applications

Option 5
Managed infrastructure for critical components

42. Implement a Proper Backup Strategy

A robust backup strategy should include:

Daily backups
+
Weekly backups
+
Application/database backups
+
Off-server backups
+
Long-retention snapshots
+
Recovery testing

A backup that has never been tested is only a theoretical backup.

43. Follow the 3-2-1 Backup Principle

3 copies of important data
2 different storage locations/media
1 copy off the primary server

For example:

Production
     +
DigitalOcean backup
     +
Off-site object storage

44. Common Mistakes to Avoid

45. Complete DigitalOcean Recovery Checklist

Phase 1 — Containment

• Stop unnecessary modifications to the compromised server.
• Take a snapshot of the compromised Droplet.
• Preserve logs and suspicious files.
• Identify affected websites.
• Determine whether multiple applications are affected.

Phase 2 — Backup Investigation

• Open DigitalOcean Backups.
• Identify backup dates.
• Determine approximately when the compromise happened.
• Select the latest backup that predates the compromise.
• Preserve a known-clean backup as a snapshot where appropriate.

Phase 3 — Recovery Environment

• Create a new Droplet from the suspected clean backup.
• Give the new server a temporary IP.
• Do not change production DNS yet.
• Verify /var/www.
• Verify databases.
• Inspect server configuration.

Phase 4 — Security Investigation

• Review SSH keys.
• Review SSH login history.
• Review user accounts.
• Review sudo configuration.
• Review cron jobs.
• Review systemd services.
• Review open ports.
• Review FTP/SFTP configuration.
• Review database users.
• Search for malicious PHP.
• Determine the likely attack vector.

Phase 5 — Production Rebuild

• Provision a clean server.
• Configure SSH keys.
• Create a non-root sudo user.
• Configure Cloud Firewall.
• Disable unnecessary services.
• Update the operating system.
• Install supported PHP/web server versions.
• Configure HTTPS.
• Restore verified website files.
• Restore verified databases.

Phase 6 — Credential Rotation

• Generate new SSH keys.
• Change SFTP/FTP credentials.
• Change CMS administrator passwords.
• Change database passwords.
• Rotate API tokens.
• Rotate SMTP credentials.
• Rotate Cloudflare credentials where appropriate.
• Revoke unknown DigitalOcean tokens and keys.

Phase 7 — Testing

• Test all websites.
• Test databases.
• Test forms.
• Test email.
• Test uploads.
• Test APIs.
• Test payments.
• Test SSL.
• Scan files.
• Review logs.

Phase 8 — DNS Migration

• Update DNS to the new server.
• Verify DNS propagation.
• Monitor traffic.
• Monitor authentication logs.
• Monitor filesystem changes.

Phase 9 — Long-Term Security

• Enable automated backups.
• Maintain off-server backups.
• Perform regular security updates.
• Remove unused plugins/software.
• Restrict database access.
• Review firewall rules.
• Schedule security audits.
• Periodically test disaster recovery.

46. Recommended Recovery Architecture

                         INTERNET
                            |
                     Cloud Firewall
                            |
              +-------------+-------------+
              |             |             |
             80            443            22
              |             |             |
              +-------------+-------------+
                            |
                         NGINX
                            |
             +--------------+--------------+
             |              |              |
          Website A      Website B      Website C
             |              |              |
          PHP-FPM        PHP-FPM        PHP-FPM
             |              |              |
             +--------------+--------------+
                            |
                     MySQL / MariaDB
                    (not publicly exposed)

                Automated Backups
                        +
                Off-site Backups
                        +
                   Monitoring

For high-value projects, further isolation can be introduced with separate Droplets or containers.

47. What the Suspicious PHP Code Means

The specific code pattern shown in the compromised server contains several red flags:

Obfuscated variable names
        +
goto-based control flow
        +
hexadecimal PHP strings
        +
dynamic function construction
        +
curl requests
        +
HTTP GET input
        +
runtime execution
        +
file/content retrieval

This combination is consistent with a malicious loader/backdoor rather than normal website functionality.

48. The Safest Overall Solution

                 COMPROMISED SERVER
                        |
                 Take snapshot
                        |
              Preserve forensics
                        |
              Find clean backup
                        |
                        ↓
              Create NEW DROPLET
                        |
                 Verify backup
                        |
                Rebuild securely
                        |
       +----------------+----------------+
       |                |                |
   Website 1        Website 2        Website 3
       |                |                |
       +----------------+----------------+
                        |
                  Restore databases
                        |
                Rotate credentials
                        |
                 Harden server
                        |
                  Security scan
                        |
                    Test sites
                        |
                   Update DNS
                        |
                     MONITOR

This approach minimizes the chance of carrying hidden persistence from the compromised environment into production.

49. Final Recommendations

If a DigitalOcean server hosting several websites has been compromised and its web files have been replaced by obfuscated PHP malware, do not treat it as a routine website restoration.

The strongest recovery strategy is to:

1. Preserve the compromised server.
2. Take a snapshot.
3. Identify a backup created before the compromise.
4. Create a separate recovery Droplet from that backup.
5. Verify the website files and databases.
6. Investigate SSH, FTP, cron, systemd and other persistence mechanisms.
7. Determine the likely initial attack vector.
8. Build a fresh production environment.
9. Restore only verified application data.
10. Rotate every credential that may have been exposed.
11. Harden SSH, firewall, PHP, web server and database access.
12. Enable reliable automated and off-site backups.
13. Move DNS to the newly secured server.
14. Monitor the environment after migration.

Useful DigitalOcean Documentation

The recovery process should be cross-checked against DigitalOcean's current documentation for:

• creating a new Droplet from a backup;
• restoring a Droplet from a backup;
• converting backups into snapshots;
• configuring SSH keys;
• setting up a production-ready Droplet;
• configuring Cloud Firewalls.

DigitalOcean's control panel, backup policies, and supported configurations can change over time, so verify the current interface and retention settings before beginning a live recovery.