Restoring Plesk, new drive, old disk still available on same system.
Here was the scenario I faced. RHEL4 machine will not boot (according to data center), receives various library not found errors on bootup (Later, I found these errors were from an intruder who tried to install a rootkit, and it didn’t go so well. Most of /bin was corrupt).
The data center recommends that the operating system be reloaded onto a separate disk, which will become the primary, and then mount the old disk as a different mount point for reference / restore. The data center reloaded the operating system, and the customer then found our services online and asked for assistance.
Plesk actually has a nice migration tool (PleskX.pl), and as such, a disk to disk based migration is pretty easy to accomplish.
The following steps can be used:
- Mount the old drive, for example to /restore directory. If there are several partitions on the old drive, for example ‘/’ and ‘/var’, they all should be mounted as they were in the old system, so ‘/’ is mounted to /restore/ and ‘/var/’ to ‘/restore/var/’
- Stop all Plesk services in the new system with:
# /etc/init.d/psa stopall
- Copy migration agent to the old drive (make sure that there is enough free disk space to perform the dump):
# mkdir /restore/migration
# mkdir /restore/migration/archives
# cp -r /usr/local/psa/PMM/agents/shared/* /usr/local/psa/PMM/agents/PleskX/* /restore/migration
- Chroot to the root directory of the old server (/restore in our case):
# export SHELL=/bin/bash
# chroot /restore
- Start MySQL from the old drive in the new chrooted environment:
# /etc/init.d/mysql start
- Run migration agent to make Plesk dump (note, this may take a few hour depending on the amount of data to backup):
# cd /migration
# ./PleskX.pl --dump-all -v5
- Move all files except for dump.xml from /restore/migration/ to /restore/migration/archive directory.
- You can now import data via the Plesk control panel. Select the import option on the Server->Migration page and specify /restore/migration (used in this example) as the Working directory.
All of this could have been avoided by proper patching of systems, use of mod_security, and tested backups. We were fortunate that the data was still intact on the old drive, as no backups were ever made on this system.
The system recovered from start to finish, 50GB of data and ~200 domains in 6 hours.
If you need backup design assistance, help recovering from a bad scenario, or anything else UNIX related.. Call MNX Solutions.