Doug’s Blog

Handily dispensing information to .00000001% of the world’s population

Archive for 2018

Recovery LVM Data from RAID

Thursday, March 1st, 2018

We had a client that had an OLD fileserver box, a Thecus N4100PRO. It was completely dust-ridden and the power supply had burned out.

Since these drives were in a RAID configuration, you could not hook any one of them up to a windows box, or a linux box to see the data. You have to hook them all up to a box and reassemble the RAID.

We took out the drives (3 of them) and then used an external SATA to USB box to connect them to a Linux server running CentOS. You can use parted to see what drives are now being seen by your linux system:

parted -l | grep ‘raid\|sd’

Then using that output, we assembled the drives into a software array:

mdadm -A /dev/md0 /dev/sdb2 /dev/sdc2 /dev/sdd2

If we tried to only use two of those drives, it would give an error, since these were all in a linear RAID in the Thecus box.

If the last command went well, you can see the built array like so:

root% cat /proc/mdstat
Personalities : [linear]
md0 : active linear sdd2[0] sdb2[2] sdc2[1]
1459012480 blocks super 1.0 128k rounding

Note the personality shows the RAID type, in our case it was linear, which is probably the worst RAID since if any one drive fails, your data is lost. So good thing these drives outlasted the power supply! Now we find the physical volume:

pvdisplay /dev/md0

Gives us:

— Physical volume —
PV Name /dev/md0
VG Name vg0
PV Size 1.36 TB / not usable 704.00 KB
Allocatable yes
PE Size (KByte) 2048
Total PE 712408
Free PE 236760
Allocated PE 475648
PV UUID iqwRGX-zJ23-LX7q-hIZR-hO2y-oyZE-tD38A3

Then we find the logical volume:

lvdisplay /dev/vg0

Gives us:

— Logical volume —
LV Name /dev/vg0/syslv
VG Name vg0
LV UUID UtrwkM-z0lw-6fb3-TlW4-IpkT-YcdN-NY1orZ
LV Write Access read/write
LV Status NOT available
LV Size 1.00 GB
Current LE 512
Segments 1
Allocation inherit
Read ahead sectors 16384

— Logical volume —
LV Name /dev/vg0/lv0
VG Name vg0
LV UUID 0qsIdY-i2cA-SAHs-O1qt-FFSr-VuWO-xuh41q
LV Write Access read/write
LV Status NOT available
LV Size 928.00 GB
Current LE 475136
Segments 1
Allocation inherit
Read ahead sectors 16384

We want to focus on the lv0 volume. You cannot mount yet, until you are able to lvscan them.


Show us things are inactive currently:

inactive ‘/dev/vg0/syslv’ [1.00 GB] inherit
inactive ‘/dev/vg0/lv0′ [928.00 GB] inherit

So we set them active with:

vgchange vg0 -a y

And doing lvscan again shows:

ACTIVE ‘/dev/vg0/syslv’ [1.00 GB] inherit
ACTIVE ‘/dev/vg0/lv0′ [928.00 GB] inherit

Now we can mount with:

mount /dev/vg0/lv0 /mnt

And viola! We have our data up and accessable in /mnt to recover! Of course your setup is most likely going to look different from what I have shown you above, but hopefully this gives some helpful information for you to recover your own data.

SFTP in Perl Connecting to Legacy Server

Tuesday, January 16th, 2018

We had a client that had a need to do automated SFTPs to various sites. It turns out that some of the sites had an older SSHD that would generate an error like “DH Group Exchange reply out of range”, and that required this parameter if you were using SFTP from the command line:


Now in Perl we were using Net::SFTP and it took some finagling (yes, that’s really a word) to figure out the proper settings, so here they were in case you were having trouble. And we had to add the warn flag otherwise we would get this warning:

Couldn’t fsetstat: Permission denied

Another oddity was that when we were putting files, the SFTP server allowed multiple files with the same name! Very odd, so we had to make sure to add a $sftp->do_remove command prior to the put command.

Here is what we used for the function call:

%sftp_args =
( “user” => “myuser”,
“password” => “mypass”,
“debug” => 0,
“warn” => 0,
“ssh_args” => [ options => [ “KexAlgorithms diffie-hellman-group1-sha1″ ] ]

$sftp = Net::SFTP->new($sftp_host,%sftp_args);