GoDaddy VPS Recovery Console and Rescue Mode Tutorial:

Uncategorized
Posted on | by Rajesh Kumar

Complete GoDaddy VPS Recovery Console and Rescue Mode Tutorial: End-to-End Troubleshooting, Recovery, Disk Repair, Firewall, Nydus, Snapshot Restore, and Disk Expansion

GoDaddy VPS issues can become stressful very quickly because one problem often leads to another: SSH stops working, Recovery Console shows GRUB rescue, disk reaches 100%, snapshot restore fails, Nydus services stop, port 2224 is reported blocked, and after a plan upgrade Linux still shows the old disk size.

This tutorial consolidates the complete practical workflow we followed and turns it into a reusable master guide for GoDaddy VPS recovery.

GoDaddy’s Recovery Console is meant to help regain VPS access when normal SSH/RDP access is broken, such as after a firewall or iptables mistake. GoDaddy says the Recovery Console is available from Servers → Manage → Server Actions → Recovery Console, and port 2224 must not be blocked for Recovery Console access. (GoDaddy)

GoDaddy also documents that VPS Hosting depends on port 2224 and Nydus services, specifically nydus-ex and nydus-ex-api; if these are blocked or modified, dashboard/management capability may be disrupted. (GoDaddy)

1. Recovery Console vs Rescue Mode

Recovery Console

Recovery Console is like a browser-based screen/keyboard attached to your VPS. It shows what the server is doing during boot.

Use Recovery Console when:

SSH is not working
server is stuck at GRUB rescue
you need to see boot errors
you need emergency console access
you accidentally blocked SSH/firewall
you need to log in from browser console

Example screen you may see:

grub rescue>

At this point, you are not inside Linux. You cannot clean files, run df -h, restart services, or delete logs. You can only run limited GRUB commands.

Rescue Mode

Rescue Mode boots your VPS into a temporary Linux rescue OS. Your original VPS disk is attached as a secondary disk, usually something like /dev/sda.

Use Rescue Mode when:

normal OS does not boot
GRUB is broken
filesystem needs repair
you need to mount the original disk
you need to recover files
you need to run xfs_repair
you need to inspect partitions

Simple difference:

Recovery Console = see/control the broken server boot screen
Rescue Mode      = boot into temporary repair Linux OS

2. Common GoDaddy VPS Failure Scenarios

You may need Recovery Console or Rescue Mode for these cases:

SSH not connecting
server stuck in GRUB rescue
disk reached 100%
root filesystem corrupted
/boot partition empty or missing GRUB files
snapshot restore failed
GoDaddy says port 2224 is blocked
Nydus services not running
plan upgraded but Linux still shows old disk size
root prompt changed to bash-5.1#

3. When Server Drops to GRUB Rescue

Example error:

error: file '/grub2/i386-pc/normal.mod' not found
grub rescue>

This means GRUB cannot load its normal module. Common causes:

/boot partition damaged
GRUB files missing
kernel/initramfs missing
filesystem corruption
disk/partition changed
failed update

At grub rescue>, first list partitions:

ls

Example output:

(hd0) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1)

Check partitions one by one:

ls (hd0,gpt1)/
ls (hd0,gpt2)/
ls (hd0,gpt3)/
ls (hd0,gpt4)/

You are looking for directories like:

boot/
etc/
home/
var/
usr/

If you find /boot/grub2, try:

set root=(hd0,gptX)
set prefix=(hd0,gptX)/boot/grub2
insmod normal
normal

If /boot is a separate partition and GRUB files are directly under /grub2, try:

set root=(hd0,gptX)
set prefix=(hd0,gptX)/grub2
insmod normal
normal

But if you see that /boot is empty or normal.mod is missing, do not waste too much time. Move to Rescue Mode.

4. Entering Rescue Mode and Logging In

After enabling Rescue Mode in GoDaddy, you may receive rescue credentials.

SSH command example:

ssh rescue_user@SERVER_IP

If you get this warning:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Host key verification failed.

It is expected because Rescue Mode uses a different temporary OS and SSH host key.

Fix on your local machine:

ssh-keygen -R SERVER_IP

Then connect again:

ssh rescue_user@SERVER_IP

Type:

yes

Then enter the rescue password.

5. Identify Original Disk in Rescue Mode

Once inside Rescue Mode, run:

lsblk -f

Example:

sda
├─sda1
├─sda2 vfat
├─sda3 xfs
└─sda4 xfs

sdb
├─sdb2 vfat /boot/efi
├─sdb3 xfs  /boot
└─sdb4 xfs  /

In this example:

sdb = rescue OS disk
sda = original broken VPS disk

Typical GoDaddy AlmaLinux/cPanel layout:

/dev/sda1 = BIOS boot
/dev/sda2 = EFI
/dev/sda3 = /boot
/dev/sda4 = /

Confirm partition table:

fdisk -l /dev/sda

6. Mount Original VPS Disk

Create mount point and mount root partition:

mkdir -p /mnt/original
mount /dev/sda4 /mnt/original

Check usage:

df -h /mnt/original

Mount boot partition:

mkdir -p /mnt/original/boot
mount /dev/sda3 /mnt/original/boot

Check boot usage:

df -h /mnt/original/boot

Inspect root filesystem:

ls -lah /mnt/original

A healthy Linux root should contain:

bin
boot
dev
etc
home
lib
lib64
opt
proc
root
run
sbin
tmp
usr
var

If critical directories are missing:

/etc
/bin
/sbin
/lib
/lib64
/root

then the OS is seriously damaged or incomplete.

7. Check Whether Disk Is Actually Full

From rescue mode:

df -h /mnt/original
du -h --max-depth=1 /mnt/original | sort -h

Check /home:

du -h --max-depth=2 /mnt/original/home | sort -h

Check largest files:

find /mnt/original -xdev -type f -printf '%s %p\n' | sort -nr | head -50

Check backups, WordPress configs, SQL dumps, archives:

find /mnt/original \
  -iname '*mysql*' -o \
  -iname '*wp-config*' -o \
  -iname '*.sql' -o \
  -iname '*.tar*' -o \
  -iname '*.zip' | head -100

Check cPanel traces:

find /mnt/original -maxdepth 5 \
  -iname '*cpanel*' -o \
  -iname 'userdata' -o \
  -iname 'domains' | head -100

8. XFS Filesystem Repair

If original root partition is XFS, first unmount it:

umount /mnt/original/boot
umount /mnt/original

Run dry-run repair first:

xfs_repair -n /dev/sda4

If dry-run shows issues, run actual repair:

xfs_repair /dev/sda4

Then mount again:

mkdir -p /mnt/original
mount /dev/sda4 /mnt/original

Check:

ls -lah /mnt/original
find /mnt/original -maxdepth 2 -name 'lost+found' -type d -print

Important: xfs_repair may fix metadata, but it cannot magically restore deleted OS files if the data is gone.

9. When to Stop Local Repair and Ask for Snapshot Restore

If you find only a few files left, or critical directories are missing, stop trying local repair.

Bad signs:

/etc missing
/bin missing
/lib64 missing
/root missing
/boot empty
/home websites nearly empty
only a few files remain

At this point, ask GoDaddy for snapshot restore.

Message template:

Hello GoDaddy Support,

My VPS became unbootable and dropped into GRUB rescue mode with this error:

file /grub2/i386-pc/normal.mod not found

I enabled Rescue Mode and mounted the original disk.

Original disk: /dev/sda
Original root partition: /dev/sda4
Original boot partition: /dev/sda3

The filesystem appears damaged/incomplete. Critical OS directories such as /etc, /bin, /sbin, /lib, /lib64, /root, and normal /boot files are missing.

Please restore the full VPS from the latest available snapshot/backup before the issue occurred.

If full restore is not possible, please attach the backup/snapshot as a secondary disk so I can recover website files, databases, emails, and cPanel data.

Please do not rebuild/reinstall the VPS until backup/snapshot options are confirmed.

GoDaddy’s own guidance for port/Nydus problems also mentions restoring from a backup when you know a recent date when the server was operational, and rebuild only after other options are exhausted. (GoDaddy)

10. Restore vs Rebuild

Restore

Restore means GoDaddy uses an old backup/snapshot to bring back your full server.

Best option if available.

It can restore:

OS
cPanel/WHM
Apache/Nginx
PHP
MySQL/MariaDB
website files
email data
DNS/cPanel configs
SSLs
cron jobs

Rebuild

Rebuild means fresh OS install.

Danger:

It can wipe old data.

Only rebuild if:

no snapshot exists
you have external backups
GoDaddy confirms restore is impossible

11. Port 2224 and Nydus Services

GoDaddy states that VPS Hosting requires port 2224 and Nydus services nydus-ex and nydus-ex-api; if blocked or modified, service disruption may happen. (GoDaddy)

Check services:

systemctl is-active nydus-ex.service nydus-ex-api.service

Expected:

active
active

Detailed status:

systemctl status nydus-ex.service --no-pager -l
systemctl status nydus-ex-api.service --no-pager -l

Logs:

journalctl -u nydus-ex.service -n 80 --no-pager
journalctl -u nydus-ex-api.service -n 80 --no-pager

12. Fix Nydus Log File Issues

In our real case, nydus-ex failed because:

FileNotFoundError: No such file or directory: /var/log/nydus/worker.log
ValueError: Unable to configure handler 'rotfile'

Fix:

mkdir -p /var/log/nydus
touch /var/log/nydus/worker.log
chmod 755 /var/log/nydus
systemctl restart nydus-ex.service

Then verify:

systemctl status nydus-ex.service --no-pager -l

For nydus-ex-api, we saw:

PermissionError: Permission denied: /var/log/nydus/server.log
ValueError: Unable to configure handler 'rotfile'

Temporary repair:

touch /var/log/nydus/server.log /var/log/nydus/worker.log
chown -R root:root /var/log/nydus
chmod 777 /var/log/nydus
chmod 666 /var/log/nydus/server.log /var/log/nydus/worker.log
systemctl restart nydus-ex.service nydus-ex-api.service

Verify:

systemctl is-active nydus-ex.service nydus-ex-api.service

Expected:

active
active

Security note: 777 and 666 are temporary emergency permissions to get the GoDaddy agent running. Once GoDaddy finishes upgrade/restore, ask support for the correct ownership/permission for /var/log/nydus, or tighten carefully.

13. Check Port 2224 Firewall Status

GoDaddy’s firewallD example is:

firewall-cmd --permanent --zone=public --add-port=2224/tcp
firewall-cmd --reload
firewall-cmd --list-ports

But on some AlmaLinux/cPanel VPS systems, firewall-cmd may not exist:

firewall-cmd: command not found
Unit firewalld.service could not be found.

Check:

systemctl status firewalld --no-pager -l

If firewalld is missing, use iptables.

Allow port 2224:

iptables -I INPUT 1 -p tcp --dport 2224 -j ACCEPT

Verify:

iptables -L INPUT -n --line-numbers | grep 2224
iptables -S INPUT

Good output:

-P INPUT ACCEPT
-A INPUT -p tcp -m tcp --dport 2224 -j ACCEPT

If you temporarily want to open OS firewall completely:

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -S

Expected:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Important: If ss -lntp | grep 2224 shows nothing, it means no service is listening on 2224. That is different from firewall blocking. A port can be allowed but still appear closed externally if no process listens.

Check listener:

ss -lntp | grep 2224

Check Nydus listeners/connections:

ss -lntp | grep nydus
ss -antp | grep nydus

If GoDaddy says 2224 is blocked, but your OS firewall is open, tell them:

firewalld is not installed.
iptables INPUT policy is ACCEPT.
Port 2224 is explicitly allowed.
Both nydus-ex and nydus-ex-api are active.
No process is listening locally on 2224, so please confirm whether Nydus is expected to bind to port 2224 or whether this is a GoDaddy platform/network firewall check.

14. Fix Root Prompt Showing bash-5.1#

If after recovery you see:

bash-5.1#

but you expected:

[root@server ~]#

Check root identity:

id

If output is:

uid=0(root) gid=0(root) groups=0(root)

then you are root. The prompt issue is usually shell profile related.

Check files:

ls -lah /root/.bashrc /root/.bash_profile /etc/profile /etc/bashrc 2>/dev/null
echo "$PS1"

If /root/.bashrc and /root/.bash_profile are empty, recreate them:

cat > /root/.bashrc <<'EOF'
# .bashrc

if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

alias ls='ls --color=auto'
alias ll='ls -alF --color=auto'
alias la='ls -A --color=auto'

export PS1='[\u@\h \W]\$ '
EOF

cat > /root/.bash_profile <<'EOF'
# .bash_profile

if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi
EOF

source /root/.bashrc

Now prompt should become:

[root@47 home]#

15. Check Filesystem Permissions Safely

Do not run dangerous commands like:

chmod -R 755 /
chown -R root:root /

These can destroy cPanel, mail, MySQL, website users, SSH keys, and application permissions.

Instead, inspect:

ls -ld / /root /etc /var /var/log /var/log/nydus /opt /opt/nydus /home

Healthy examples:

/              root:root
/etc           root:root
/home          root:root
/opt           root:root
/opt/nydus     nydus:nydus
/root          root:root
/var           root:root
/var/log       root:root

16. After GoDaddy Plan Upgrade: Disk Shows 400 GB but Linux Still Shows 199 GB

This is very common.

First check:

lsblk
df -kh

Example before expansion:

sda      400G disk
└─sda4   198.8G part /

df -kh /
/dev/sda4 199G 195G 4.7G 98% /

Meaning:

GoDaddy expanded virtual disk
Linux partition/filesystem not expanded yet

Install growpart if missing:

dnf install -y cloud-utils-growpart

Expand partition 4:

growpart /dev/sda 4

Example success:

CHANGED: partition=4 start=2510848 old: size=416916481 end=419427328 new: size=836349919 end=838860766

For XFS filesystem, expand root filesystem:

xfs_growfs /

Verify:

df -kh /
lsblk

Expected:

/dev/sda4 399G 196G 204G 50% /
sda4      398.8G part /

Final status example:

Disk:        /dev/sda = 400G
Root part:   /dev/sda4 = 398.8G
Filesystem:  / = 399G
Used:        196G
Available:   204G
Usage:       50%

17. Disk Full Cleanup Checklist After Server Is Booting

Once the server is booting normally and has enough space, clean safely.

Check top-level usage:

df -kh
du -h --max-depth=1 / | sort -h

Check /home:

du -h --max-depth=1 /home | sort -h

Check /var:

du -h --max-depth=1 /var | sort -h

Check logs:

du -h --max-depth=1 /var/log | sort -h
du -h --max-depth=1 /usr/local/cpanel/logs | sort -h

Check cPanel backups:

du -h --max-depth=2 /backup 2>/dev/null | sort -h
du -h --max-depth=2 /home/*/backup* 2>/dev/null | sort -h

Check large files:

find / -xdev -type f -size +500M -printf '%s %p\n' 2>/dev/null | sort -nr | head -50

Check deleted files still held open:

lsof +L1

If a deleted log is held by a service, restart the service instead of rebooting blindly.

18. Safe Log Cleanup Examples

Do not delete random files. Truncate logs safely:

truncate -s 0 /var/log/messages
truncate -s 0 /var/log/secure
truncate -s 0 /var/log/maillog

For cPanel logs:

du -sh /usr/local/cpanel/logs/*

Truncate selected large logs:

truncate -s 0 /usr/local/cpanel/logs/error_log
truncate -s 0 /usr/local/cpanel/logs/queueprocd.log

Clear temporary files carefully:

find /tmp -type f -mtime +2 -delete
find /var/tmp -type f -mtime +2 -delete

For package cache:

dnf clean all

19. Recommended Communication With GoDaddy

When port 2224 is open but they still say blocked

I verified the VPS OS firewall.

firewalld is not installed.
iptables -S INPUT shows default policy ACCEPT.
TCP port 2224 is explicitly allowed.
Both Nydus services are active.

However, ss -lntp | grep 2224 shows no local listener on port 2224.

Please confirm whether Nydus is expected to bind locally to 2224, or whether this is checked at the GoDaddy platform/network firewall layer.

When Nydus is fixed

I fixed the Nydus issue.

nydus-ex.service is active.
nydus-ex-api.service is active.
The OS firewall is open.
Please refresh the dashboard capability check and proceed with upgrade/restore.

When disk upgrade is completed

The VPS disk upgrade is now visible inside Linux.

Current status:
Disk /dev/sda = 400G
Partition /dev/sda4 = 398.8G mounted on /
Filesystem /dev/sda4 = 399G total, 196G used, 204G available, 50% used

I expanded the partition using growpart /dev/sda 4 and expanded XFS using xfs_growfs /.

20. Full Emergency Command Flow

Use this as a quick checklist.

In Recovery Console GRUB rescue

ls
ls (hd0,gpt1)/
ls (hd0,gpt2)/
ls (hd0,gpt3)/
ls (hd0,gpt4)/

In Rescue Mode

lsblk -f
fdisk -l /dev/sda
mkdir -p /mnt/original
mount /dev/sda4 /mnt/original
df -h /mnt/original
ls -lah /mnt/original

Mount boot

mkdir -p /mnt/original/boot
mount /dev/sda3 /mnt/original/boot
df -h /mnt/original/boot
ls -lah /mnt/original/boot

Repair XFS

umount /mnt/original/boot
umount /mnt/original
xfs_repair -n /dev/sda4
xfs_repair /dev/sda4

Check Nydus

systemctl is-active nydus-ex.service nydus-ex-api.service
systemctl status nydus-ex.service --no-pager -l
systemctl status nydus-ex-api.service --no-pager -l
journalctl -u nydus-ex.service -n 80 --no-pager
journalctl -u nydus-ex-api.service -n 80 --no-pager

Fix Nydus logs

mkdir -p /var/log/nydus
touch /var/log/nydus/server.log /var/log/nydus/worker.log
chmod 777 /var/log/nydus
chmod 666 /var/log/nydus/server.log /var/log/nydus/worker.log
systemctl restart nydus-ex.service nydus-ex-api.service
systemctl is-active nydus-ex.service nydus-ex-api.service

Check firewall

systemctl status firewalld --no-pager -l
iptables -S INPUT
iptables -L INPUT -n --line-numbers | grep 2224
ss -lntp | grep 2224

Open iptables temporarily

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -S

Expand disk after GoDaddy upgrade

lsblk
df -kh /
dnf install -y cloud-utils-growpart
growpart /dev/sda 4
xfs_growfs /
df -kh /
lsblk

21. Final Best Practices

Keep these rules in mind:

Do not rebuild unless backup restore is impossible.
Do not run recursive chmod/chown on /.
Do not delete files while unsure.
Do not assume port 2224 is blocked only because no listener appears.
Do not confuse Recovery Console with Rescue Mode.
Always check lsblk before mounting disks.
Always run xfs_repair -n before actual repair.
Always expand both partition and filesystem after VPS disk upgrade.

The safest recovery order is:

1. Use Recovery Console to observe boot problem.
2. Use Rescue Mode to inspect/mount/repair disk.
3. If OS/data is missing, request snapshot restore.
4. Fix port 2224/Nydus if GoDaddy dashboard capability is limited.
5. After plan upgrade, expand partition using growpart.
6. Expand XFS filesystem using xfs_growfs.
7. Verify df -kh and lsblk.
8. Clean disk only after server is stable.

This workflow gives you a reliable, end-to-end method to handle GoDaddy VPS emergencies without accidentally wiping data or making recovery harder.