I had a power issue in my home and now my readynas no longer powers on. I swapped out the PSU with a ATX PSU from another computer ( I do not have a spare for the readynas ) and it will still no longer power on. I know this is a very old device. If I purchase a newer model as a replacement can I put my drives in it without issue? I remember reading somewhere that due to the CPU in this device, drives from it put into a newer device will not see the existing data.
If you could let me know what my options are here, I'd appreciate it.
If you actually have an NV+ v1, then it should be running 4.1.x firmware. An NV+ v2 would be running 5.3.x. An ultra or a pro would be running 4.2.x firmware.
There should be a sticker on the back which shows you the firmware that was installed at the factory. You can post back with that information along with the full part number on the back, and we can confirm what platform you have.
As the KB article says, with support's assistance you can mount your data volume temporarily in a new OS 6 NAS. You'll then have to off-load the data to backup, do a factory reset/system setup, and then restore the data from your backup. They might charge for that, and if the failure caused any corruption of the file system you might need their data recovery service.
It's definitely a version 1. The back says FW 4.1.6. The full part number is RND4000 v3 which is below the firmware sticker. There is another part number on the bottom of the PSU that says RND4210-100NAS. Either way though it looks like it's a 4.1.x. I picked up a 214 with empty drive bays and will be calling support later today. I had a little bit of trouble finding the right model on the website. I'm not sure how old the 214 is compared to other models but it seems like it'll do the job.
It's definitely a version 1. The back says FW 4.1.6. The full part number is RND4000 v3 which is below the firmware sticker. There is another part number on the bottom of the PSU that says RND4210-100NAS.
I'm not sure how old the 214 is compared to other models but it seems like it'll do the job.
It was announced in the fall of 2015. The 200 series is intended for home users, and uses an ARM processor. It's a lot faster than your v1 (perhaps 5x faster).
I'm waiting for a call back from Level 3. They charged me the $200. I also asked them about being able to move these 4 drives and add two more to a 316 ( as an alternative to having to purchase 4 new drives to upgrade space ). They told me that they are different achitectures and I'd have to backup everything, blow away the 4 drives and add the 2 new ones, and then move it all back. Is this correct?
They told me that they are different achitectures and I'd have to backup everything, blow away the 4 drives and add the 2 new ones, and then move it all back. Is this correct?
The architectures are very different - the file system is BTRFS, not EXT, the RAID is software-based (in your NV+ v1 it's hardware accelerated), the linux is of course current.
Sorry I wasn't clear. I have a 214 today that is now fully populated with the 4 drives from my old NAS. In the future at some point I may need to add more storage as right now they are just 4x2TB drives. I asked the tech if I could buy a 316 and simply move the 4 drives over to the 316 from the 214, add the two additional 2TB drives, and expand the volume. This would save me from having to buy 4 new drives and replace them one at a time on the 214. He told me that this isn't possible since the 200 series are consumer grade while the 300+ series are meant for small businesses and use a different architecture. I'd have to do the same process, evacuate all data off the 214 to a different location, move the 4 drives and add two more to the 316, and move it back. I just wanted to see if this was accurate or not.
I asked the tech if I could buy a 316 and simply move the 4 drives over to the 316 from the 214, add the two additional 2TB drives, and expand the volume. ... He told me that this isn't possible since the 200 series are consumer grade
He's wrong on that. You can migrate the drives - the RN316 will install the x86 OS (instead of arm), and will retain your data and settings.
Uninstall your apps first! Many are arm/x86 specific, and they won't migrate.
It is of course always good to have a current backup when you are manipulating drives.
That's good to know. I got the 214 at Frys price matched to Amazon for $300. The 316 on Amazon is $500. That plus two more drives would cost me $340 more after I return the 214 to Frys. It'd bring my total usable to right under 10TB, almost double the space from what I have now. 4x4TB drives in the 214 would be a little bit higher usable ( around 1TB or so ) but would cost me nearly $600, almost double, since I'd have to buy 4 new drives at double the capacity.
Nothing back yet from Level 3. I called in yesterday and was promised a call back by COB. Nothing. Called in again this morning and was told they would escaate to the manager but could not guarantee a call back. So far I'm not thrilled considering I'm paying for this 😕
Well, to say I am disappointed would be a stretch. So far no one has called me back. They keep telling me they have no way to reach Level 3 outside of e-mail and refuse to do anything even though they've e-mailed twice already. He assured me that they have no possible way to call anyone in level 3 on any of their teams throughout the world......think about that for a second.
They keep stating data recovery has a 96 hour return time but they don't seem to be able to tell me when that timer state. I spoke to a Level 2 supervisor named Stefan who told me data recovery is a low priority item and the 96 hour timer is between responses. When I pointed out to him that had already passed he didn't seem to care that they violated their own SLA and said he'd just send an e-mail, which is the third time I've had them do that. They just seem to ignore them. I told Stefan I'd call him back the same time tomorrow to have him send another e-mail.
At this point I am debating on whether or not I just want to mount the drives in a BSD machine and copy the data off myself......any ideas here?
# mdadm --detail /dev/md2 /dev/md2: Version : 0.90 Creation Time : Fri Jul 15 03:59:08 2016 Raid Level : raid5 Array Size : 5852786688 (5581.65 GiB 5993.25 GB) Used Dev Size : 1950928896 (1860.55 GiB 1997.75 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 2 Persistence : Superblock is persistent
Update Time : Sat Dec 2 23:49:47 2017 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0
Layout : left-asymmetric Chunk Size : 4096K
UUID : b601574d:0ddd6101:c3b35ea2:dc9e17d5 (local to host 566bbb3d) Events : 2274621.0
Number Major Minor RaidDevice State 0 8 35 0 active sync /dev/sdc3 1 8 51 1 active sync /dev/sdd3 2 8 3 2 active sync /dev/sda3 3 8 19 3 active sync /dev/sdb3 #
# pvscan Incorrect metadata area header checksum on /dev/md2 at offset 16384 PV /dev/md2 lvm2 [5.45 TiB] Total: 1 [5.45 TiB] / in use: 0 [0 ] / in no VG: 1 [5.45 TiB] #
# vgscan Reading all physical volumes. This may take a while... Incorrect metadata area header checksum on /dev/md2 at offset 16384 #
It seems to be healthy. I got into it via telnet while it is in tech support mode. It doesn't seem to be able to find it though due to the 16k block size.
# vgscan -vv Setting activation/monitoring to 1 Setting global/locking_type to 1 Setting global/wait_for_locks to 1 File-based locking selected. Setting global/prioritise_write_locks to 1 Setting global/locking_dir to /var/lock/lvm Setting global/use_lvmlockd to 0 Locking /var/lock/lvm/P_global WB Wiping cache of LVM-capable devices Wiping internal VG cache Reading all physical volumes. This may take a while... Using volume group(s) on command line. /dev/loop0: size is 0 sectors /dev/sda: size is 3907029168 sectors /dev/md0: size is 4095872 sectors /dev/md0: size is 4095872 sectors /dev/md0: No label detected /dev/loop1: size is 0 sectors /dev/sda1: size is 4096000 sectors /dev/sda1: size is 4096000 sectors /dev/loop2: size is 0 sectors /dev/sda2: size is 1048576 sectors /dev/sda2: size is 1048576 sectors /dev/md2: size is 11705573376 sectors /dev/md2: size is 11705573376 sectors /dev/md2: lvm2 label detected at sector 1 Incorrect metadata area header checksum on /dev/md2 at offset 16384 /dev/loop3: size is 0 sectors /dev/sda3: size is 3901865984 sectors /dev/sda3: size is 3901865984 sectors /dev/loop4: size is 0 sectors /dev/loop5: size is 0 sectors /dev/loop6: size is 0 sectors /dev/loop7: size is 0 sectors /dev/sdb: size is 3907029168 sectors /dev/sdb1: size is 4096000 sectors /dev/sdb1: size is 4096000 sectors /dev/sdb2: size is 1048576 sectors /dev/sdb2: size is 1048576 sectors /dev/sdb3: size is 3901865984 sectors /dev/sdb3: size is 3901865984 sectors /dev/sdc: size is 3907029168 sectors /dev/sdc1: size is 4096000 sectors /dev/sdc1: size is 4096000 sectors /dev/sdc2: size is 1048576 sectors /dev/sdc2: size is 1048576 sectors /dev/sdc3: size is 3901865984 sectors /dev/sdc3: size is 3901865984 sectors /dev/sdd: size is 3907029168 sectors /dev/sdd1: size is 4096000 sectors /dev/sdd1: size is 4096000 sectors /dev/sdd2: size is 1048576 sectors /dev/sdd2: size is 1048576 sectors /dev/sdd3: size is 3901865984 sectors /dev/sdd3: size is 3901865984 sectors No volume groups found. Unlocking /var/lock/lvm/P_global #
It sees the label as lvm2 but won't do anything with it.
vgscan
Reading volume groups from cache.
Found volume group "c" using metadata type lvm2
pvs
PV VG Fmt Attr PSize PFree
/dev/md127 c lvm2 a-- 5.45t 0
lvdisplay c
--- Logical volume ---
LV Path /dev/c/c
LV Name c
VG Name c
LV UUID NlKR34-7CHi-mTLU-McCD-bvOF-3M9m-gqC0TP
LV Write Access read/write
LV Creation host, time ,
LV Status suspended
# open 0
LV Size 5.45 TiB
Current LE 178613
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:3
vgdisplay
--- Volume group ---
VG Name c
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 5.45 TiB
PE Size 32.00 MiB
Total PE 178613
Alloc PE / Size 178613 / 5.45 TiB
Free PE / Size 0 / 0
VG UUID 0Nidfo-3d2b-ayh1-yl48-R0HE-8G11-5jEEby
pvdisplay
--- Physical volume ---
PV Name /dev/md127
VG Name c
PV Size 5.45 TiB / not usable <4.19 MiB
Allocatable yes (but full)
PE Size 32.00 MiB
Total PE 178613
Free PE 0
Allocated PE 178613
PV UUID izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
However when I tried to mount the filesystem, it refused to do so:
vgchange -ay c
device-mapper: resume ioctl on (253:3) failed: Invalid argument
Unable to resume c-c (253:3)
1 logical volume(s) in volume group "c" now active
In the log I found this:
Dec 14 18:14:48 localhost kernel: device-mapper: table: 253:3: md127 too small for target: start=384, len=11705581568, dev_size=11705573376
Which seemed to indicate that the LVM was too large for the physical drive. Looking into this further showed this:
[root@localhost ~]# lvs --partial --segments -o+devices /dev/c/c
PARTIAL MODE. Incomplete logical volumes will be processed.
WARNING: Cannot find matching striped segment for c/c.
LV VG Attr #Str Type SSize Devices
c c -wi-XX--X- 1 linear 5.45t /dev/md127(0)
[root@localhost ~]# blockdev --getsize64 /dev/md127
5993253568512
[root@localhost ~]# pvdisplay --units=b /dev/md127
--- Physical volume ---
PV Name /dev/md127
VG Name c
PV Size 5993257959424 B / not usable 4390912 B
Allocatable yes (but full)
PE Size 33554432 B
Total PE 178613
Free PE 0
Allocated PE 178613
PV UUID izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
[root@localhost ~]#
The PV is about 4MB too large compared to the underlying device which is why the error is being generated. Trying to mount the filesystem with fuseext2 just spits out this error:
[root@localhost /]# export Sectors=11705573376
[root@localhost /]# echo $Sectors
11705573376
[root@localhost /]# echo -e "0 $Sectors linear /dev/md127 0\\n$Sectors 10240 zero" | dmsetup create zzbigdev
[root@localhost /]# pvs
WARNING: Not using lvmetad because duplicate PVs were found.
WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
WARNING: PV izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4 on /dev/md127 was already found on /dev/mapper/zzbigdev.
WARNING: PV izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4 prefers device /dev/md127 because device size is correct.
PV VG Fmt Attr PSize PFree
/dev/md127 c lvm2 a-- 5.45t 0
[root@localhost /]# vi /etc/lvm/lvm.conf
[root@localhost /]# pvs
WARNING: Not using lvmetad because duplicate PVs were found.
WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
PV VG Fmt Attr PSize PFree
/dev/mapper/zzbigdev c lvm2 a-- 5.45t 0
[root@localhost /]# lsblk -f
lsblk: dm-0: failed to get device path
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 linux_raid_mem 405d4d6e-3d7b-3855-38c5-5bffbe3d3acf
├─sda2 linux_raid_mem 9de95ef7-25d0-d5d1-f949-8eac13ed460e
└─sda3 linux_raid_mem c423356a-6ccf-4040-8380-0237772ec525
└─md127 LVM2_member izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
└─zzbigdev
LVM2_member izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
sdb
├─sdb1 linux_raid_mem 405d4d6e-3d7b-3855-38c5-5bffbe3d3acf
├─sdb2 linux_raid_mem 9de95ef7-25d0-d5d1-f949-8eac13ed460e
└─sdb3 linux_raid_mem c423356a-6ccf-4040-8380-0237772ec525
└─md127 LVM2_member izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
└─zzbigdev
LVM2_member izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
sdc
├─sdc1 linux_raid_mem 405d4d6e-3d7b-3855-38c5-5bffbe3d3acf
├─sdc2 linux_raid_mem 9de95ef7-25d0-d5d1-f949-8eac13ed460e
└─sdc3 linux_raid_mem c423356a-6ccf-4040-8380-0237772ec525
└─md127 LVM2_member izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
└─zzbigdev
LVM2_member izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
sdd
├─sdd1 linux_raid_mem 405d4d6e-3d7b-3855-38c5-5bffbe3d3acf
├─sdd2 linux_raid_mem 9de95ef7-25d0-d5d1-f949-8eac13ed460e
└─sdd3 linux_raid_mem c423356a-6ccf-4040-8380-0237772ec525
└─md127 LVM2_member izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
└─zzbigdev
LVM2_member izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
sde
├─sde1 xfs 938e082d-2f80-42e0-9738-b4c2e497eb4f /boot
├─sde2 swap 9a85f1c1-27c4-40fa-86da-1068494bd393 [SWAP]
├─sde3 xfs ab32bd8f-f600-49cc-a27a-9201c64a0f60 /
├─sde4
└─sde5 xfs 149009a3-f7f4-47d1-8186-3b22a947c114 /home
loop0
loop1
loop2
[root@localhost /]# pvdisplay
WARNING: Not using lvmetad because duplicate PVs were found.
WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
--- Physical volume ---
PV Name /dev/mapper/zzbigdev
VG Name c
PV Size 5.45 TiB / not usable <4.19 MiB
Allocatable yes (but full)
PE Size 32.00 MiB
Total PE 178613
Free PE 0
Allocated PE 178613
PV UUID izLiST-kTJw-E77o-8UIf-d6J7-tDt2-ZjKGQ4
[root@localhost /]# vgchange -ay c
WARNING: Not using lvmetad because duplicate PVs were found.
WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
Attempted to decrement suspended device counter below zero.
1 logical volume(s) in volume group "c" now active
[root@localhost /]# fuseext2 -o ro -o sync_read /dev/c/c /mnt/lvm/
[root@localhost /]# ls -lah /mnt/lvm/
total 112K
drwxrwxrwx. 6 root root 16K Nov 14 16:26 .
drwxr-xr-x. 3 root root 17 Jan 2 13:17 ..
-rw-------. 1 root root 7.0K Nov 14 16:26 aquota.group
-rw-------. 1 root root 7.0K Nov 14 16:27 aquota.user
drwxr-xr-x. 2 98 98 16K Jul 14 2016 home
drwxrwxrwx. 19 1000 nfsnobody 16K Sep 2 13:38 homeshare
drwx------. 2 root root 16K Jul 14 2016 lost+found
drwxr-xr-x. 2 96 root 16K Jul 14 2016 .timemachine
[root@localhost /]#
What I did was calculate the amount of sectors by diving the array size by 512. I then set a sector system variable and passed it through to create a new PV at the proper size. Since it was the same data, I had to filter out the wrong UUID in lvm.conf and then try to mount it at which point it mounted fine and I was able to see the filesystem.
I ran into one more problem as I was using CentOS for this. The fuseext2 module is *very* old and no longer maintained. I would start to copy files and it would fail and dismount the filesystem 20-50 files in. I had to switch to Ubuntu and use their updated module ( 0.3.1 vs 0.8.1 ) which worked fine to copy all the files off.
