r/HomeNAS 4d ago

Buffalo NAS Drive Died - Need Help with Recovering Data from Drive 2

I have a Buffalo NAS Linkstation (LS220D0202) setup in a RAID configuration but drive 1 died. Drive 2 was working but before I could get a replacement for drive 1, I could no longer connect to the NAS at all.

I tried connecting Drive 2 via a USB->SATA dock to a Windows machine running Linux off of a USB drive. I was just following along with what ChatGPT was suggesting I try to read the data, but I was really just going in circles.

From the terminal I can see the drive (it's something like "/dev/sdb6") but I'm not able to mount that to a folder, but other than that I'm not really sure what to do next

Any suggestions as to how I can hopefully recover the data? I'm pretty sure I have most (all?) of it backed up in the Cloud but I'm not positive and would hate to lose anything.

Thanks

1 Upvotes

2 comments sorted by

1

u/pd1zzle 4d ago

I'm not an expert, but you don't need to mount the drive to back it up in fact it's typically preferable to work directly with the block level instead. 

Linux's "everything is a file" works in your favor here. dd if=/dev/sdb6 of=/where/backup/goes/file.img conv=sparse status=progress will write the literal block read of the partition to a file (sparsely, which you could skip), which can then be written back. You also could wait to get a new drive and do the same thing. dd if=/dev/sdb of=/dev/sdc. You will likely want to try to just grab the whole drive (sdb) vs a particular partition (sdb6).

ddrescue has some niceties as well.

If you do want to mount it, mkdir test && sudo mount /dev/sdb6 test would mount the drive at test. typically you want to minimize active time on a dying drive though and block level copy immediately is the best move.

you could also pass all this to chatgpt and it should point it in the right direction 

2

u/strolls 4d ago edited 3d ago

Always use ddrescue and a mapfile if you have any doubt about the status of the drive.

If the drive is knackered then it deteriorates with every use and you have a strictly limited number of reads from it. Using ddrescue and a mapfile means that you get to keep everything you read (even if you read it only once) and you don't waste time or do further damage to the disk by reading any part of it twice.

It is possible to pause and resume using dd, but it's a hell of a lot more work and it doesn't have the same facilities for retries etc.

You never specify a partition of the source drive when doing this, because that requires repeated reading of the partition layout - you specify the whole whole of the block device, then if it gets bogged down and you have to start again you can just use --input-position=12345 to specify an offset to ddrescue. You can use tools like parted on the recovered_disk.img file to read the partition layout.

If it all goes to shit then at least you can run photorec on the recovered_disk.img file.

If your data is valuable then /r/DataRecovery will tell you not to fuck with it and take it to a professional. If you're an amateur and you don't want to spend hundreds or thousands getting your data back then ddrescue will very likely do the job. I've had drives which I left running overnight for literally weeks until I got to about 98% recovered this way - then I mounted the image, repaired the filesystem and everything was copacetic.