Simple scenario
a linux server (Debian in this case) has run out of hard-disk capacity (4GB) and needs to be migrated to a larger capacity hard drive (6GB). Should be simple, vmware even provides a nice method to merely expand the virtual hard disk capacity. However, I’m doing this for the purposes of practice and training with various tools; as such I’m going to assume we’re working with physical hardware and this option isn’t available (despite the fact the machines being used are virtuals within my lab, I know….)
(*N.B. if following these steps on your own hardware substitute all IP addresses, device and filepaths as relevent to your environment. This is just the process that worked in my scenario, if working with your own equipment ensure that you know the impact of each command before running anything, your mileage may vary. If unsure contact an expert for further advice)
Servers involved
- Debian Server: 10.0.0.8
- Acquisition Server: 10.0.0.211
Data Acquisition
To transfer the data from the original server I used only free and freely available tools. To start the Debian server was booted from CD with Knoppix (note: nearly any Linux live CD would have been suitable for this task, previously I would have used Helix, but this is unfortunately no longer free).
Once booted, an image was collected via the venerable dd and transferred to the acquisition server via the equally venerable netcat.
Debian $ dd if=/dev/sda1 | nc 10.0.0.211 2000
Acquisition $ nc -lp 2000 | dd of=/mnt/sda1/debian-sda1.dd
I always name my images with the device or mount point that was captured. It is easy to forget further down the line whether you had imaged a partition or entire block-level device, this is the best way I have found to document what is contained in the image.
Depending on your connection speeds and hard disk capacities this transfer can take a long time, in my case the initial image capture took a little under 30 minutes. This can be unnerving the first few times through the process (especially if you are working under time constraints) is that the nc/dd combination does not provide any progress status.
One tip I’ll share is to ensure the netcat sessions are initiated via console sessions. In previous scenarios I have been remotely SSH’d to one of the servers and initiated the image transfer, only to have my remote session timeout and kill the dd/nc processes 🙁 not a nice thing to experience…
Once the image transfer completes you can verify the integrity of the acquired image by hashing; as people of started discovering issues with some hashing algorithms it is worth hashing with several algorithms for complete peace of mind. In this scenario I used the utilities md5sum and sha1sum as forensic integrity isn’t an issue in this scenario.
Prepare new drive
At this point I powered down the Debian server, deleted the original hard drive, created a new drive with larger capacity and rebooted, again with Knoppix. The drive was partitioned with fdisk, I’ll not go into specific as there are plenty of great tutorials regarding partition available elsewhere.
Replicate Data
Next task is to copy the data back from the acquisition server, this is basically a reverse of the initial dd/nc commands:
Debian $ nc -lp 2000 | dd of=/dev/sda1
Acquisition $ dd if=/mnt/sda1/debian-sda1.dd | nc 10.0.0.8 2000
Configure server to use new hard disk
At this point the re-migrated data can be mounted and utilised, is currently not bootable and it’s filesystem will not take advantage of the additional storage capacity. The latter of these issues is easily dealt with, again from within a Knoppix boot running the below command will expand the file system to it’s capacity:
$ resize2fs /dev/sda1
To allow the system to boot from the new drive grub was re-installed with the below command:
$ grub-install –root-directory=/mnt/sda1/ /dev/sda/
And with that the system boots as before, but with additional capacity required to continue operating in a useful manner.
— Andrew Waite
Leave a comment