Spinpoint F4 HD204UI 2TB 5400 RPM working good so far

Update

Ok, thanks for lordgibbness for bringing to my attention the "Hot Swappable" debacle and my misunderstanding of "Pulling disks".

He kindly posted a link to a report from dbott67 about "misconceptions of data backup". Obviously advisable for everyone to read if not done already. Link below.
http://www.readynas.com/?p=3153

mutley

wombat6025

I've managed backup and just managed to implement Rsync and verify. If you need to do the Rysnc dance, here's a link
http://www.rnasguide.com/?p=114#comment-27

It didn't go without problems for me, but managed to fill in the blanks. So if you get stuck I might be able to help there.

Onto 4.1.7 update and the rest of the 4K Duo Disk upgrade Brain Banger. With any luck the next parts will go much easier.

mutley

But still nervous for some girly reason.

update

Here's a link to another thread about the Rsync instructions and variables. http://readynas.com/forum/viewtopic.php?f=31&t=47521
Make sure to read the whole thread as it becomes self explanatory further down and could save you hours of messing about trying to configure what can't be configured. Especially the part, trying to verify your 'C' volume backup with Rysnc etc... But below is some quotes for a quick insight to comprehension.

dachtler wrote: Is there any way to setup a single rsync backup job that will backup an entire volume? I have my "C" volume with 7 shares on it. I can setup a separate rsync job for each share, but I'd prefer to just setup a single job that will backup the entire "C" volume. However, it won't seem to accept "c" in the path. Any ideas?

mdgm wrote:
You need to specify volume C as the source and the USB disk as the remote rsync target. See Rsync backup to USB disk

dachtler wrote:

mdgm wrote: You need to specify volume C as the source and the USB disk as the remote rsync target. I guess that's what I'm saying is that I don't know how to specify volume C as the source. According to the guides I've read, you specify the share without a leading / as the target. I have found nowhere where it tells how to specify the volume. If I leave the path blank, I can't save the backup job (even though I can successfully connect via the rsync test). If I try to specify "c", then I get an error with the rsync test. Any hints? Do I need to create the job via FrontView, then SSH to the Duo and edit the file?

bspachman wrote:

I'm not sure which version of RAIDiator the Duo runs, but on my Pro, in the Source step (when creating a FrontView backup), the drop down list has "Volume: c" as an option. I believe everything else in the 'Source' step can then remain blank, and the destination can be configured as the rsync job. If 'volume: c' is not an option in your drop-down menu, one of the gurus will have to weigh in... :) Hope that helps.... brad

dachtler wrote:

bspachman wrote: I'm not sure which version of RAIDiator the Duo runs, but on my Pro, in the Source step (when creating a FrontView backup), the drop down list has "Volume: c" as an option. I believe everything else in the 'Source' step can then remain blank, and the destination can be configured as the rsync job. If 'volume: c' is not an option in your drop-down menu, one of the gurus will have to weigh in... :) Hope that helps.... brad This definitely helps. I was trying to create the backup job with rsync in the source, and the USB drive as the destination. It didn't occur to me to try and switch them. Duh. Thanks, Brad.

Thanks to bspachman for starting that one. I just wished I'd read it sooner. (make sure to read whole thread and not just quotes above).

I'm done, I've had enough. Almost over and I can walk away and re-enter the rest of my life. After this, my actual real job doesn't seem so bad, almost serene (and it's far from that).

mutley

So as someone who would really like to have the Samsung 2TB drives, is this something that I should tackle as pretty easy now that you've got the learning curve flattened for us, or something only to do if you can invest the time to hack through it (which I can't)?

I can't answer that one for you. Only you know how competent you are at the moment. For me, it was a marathon because I had to have a refresh with the tech stuff with the new 4k hard drives. Then re-learn about making a backup of my Duo, which I wasn't doing and then learning how to use Rysnc to verify. I'll print a list below of a list I made up of procedures I needed to implement to get the job done. I took these instructions from various posts and banged it together. Have a look and decide for yourself how much of it you can pull off without too much trouble. Don't forget I banged 2 new disks in. It might be different for everyone.
For me, it's took a few weeks of posting/research and application. I've tried to help others with my posts above, including links to relevant info needed on other posts. The trouble like I've said is that the clever people who know what they're doing have already answered so many questions and posts already. The problem is then for people who don't know spend ages trawling for the right answers etc.....

Have a look at the list.

Duo Disk 4K Upgrade
1. Back up all data
2. Switch on Rsync and verify with a new backup
3. Update to 4.1.7
4. Make a system config backup
5. Disconnect usb external backup just in case
6. Power down and replace with 2 new discs
7. Should already be factory defaulted, but do again
8. After resync reinstall system config
9. Check start count divisible by 8 on discs for 4k alignment
10. Restore backed up data (note: can't restore whole of "c" volume in one go to the new 'c' volume. Have to do it share by share)


As for the running of the disks, it's too early to tell for me as of yet. Oh, and it does take a lot of hours of just down time backing up and rysncing etc...

I'd just like to say thankyou to everyone that did answer my questions, and to the Readynas clever people who help us along.

mutley

I'll probably be starting with 2 fresh disks, and won't back up anything from the original 500GB drive. Might also wait until the 2TB SpinPoints are on the HCL (if I can get any validation that they are getting tested...)

That process doesn't sound bad - I'm trying to get the thing set up to use as my wifes Time Machine and have just a share I can use w/ my ThinkPad to dump files on. This whole process seems pretty daunting!

You might be waiting for sometime for the Samsung F4's validation on the HCL. Seems to be a bit slow at the moment.

mutley

Update

Below is most of a post I've just spent the last 2 hours working on(I've edited it from another post I've just posted). It describes my troubled journey with trying to get Rsync to work and verify my backed data.
I actually got a few things wrong, but have decided to show my quandary to the rest of you. For anyone out there who's in my shoes a month ago, and needs a guide of what not to do and get confused about. I did notice various peoples posts of the same nature of confusion. So here below is a description of what to do and what not to get confused about. Read it all, as half way through whilst I was moaning and typing, I realised my mistake.


No where did I come across on my journey to imply that the 'c' volume couldn't be used as a standalone volume to 'restore' from as a whole. Now bear in mind, I've just backed up the 'c' volume as directed by instruction to backup all data. Common sense would lead me to think one would just reverse the process, using 'c' volume to just restore to new disks on Duo. But for whatever the reason, that's not allowed. But we're not told this, or told to 'restore' shares as individuals.

Next, I've just done multiple tests with Rsync and a dummy share. Switching the source and the destination between the tests. For clarification below:

Source
share : Rsync
host : 127.0.0.1
path : myexternalhdd/sharedummy/folderdummy


Destination
share : dummy(share on my duo)
host :
path :

And yes Rsync will work both ways.

However, the problem still remains with the 'Non' mention of the 'c' volume not working as a standalone restore point. Which like I've stated would be an obvious choice to try and restore as a whole. Obvious because it's not mentioned you can't!
So in my trawling I've come across many confused users and posts trying to get to grips with this. I've even made the same mistake as others, trying to get a restore or verification of the 'c' volume, again as instructed to do.
Upgrade to radiator 4.1.7 instructions and 4k disk upgrade;
1. Backup all data
2. Verify all data with Rsync........before upgrading etc...

So to get Rsync to verify, and work within Frontview, people are doing it back to front.

To be able to click the 'Apply' button which is grayed out if config is conflicting with Frontview. People are backing up there data. Now they want to go back into Frontview/Backup jobs/edit the job number to an Rsync job/so as to verify.
But here's the flaw.
You can't choose Rsync as the source(path to backed up data) , and then choose 'c' volume in the destination to verify against.
So people are switching and putting 'c' in the source and 'Rysnc' in the destination. Which if you're trying to verify the data you've just put back onto the Nas, then if anything got screwed up in the restore, it gets mirrored in your original Rsync backup...........


Man, I've just seen my mistake!

I'm leaving this here so people can learn from my mistake

I've got the verification sequence about face.

This is right below:
1. Backup your data from the off in Frontview/Backups with a regular backup job.
2. Go back into Frontview/Backups and edit the job for verification purposes with Rysnc enabled
3. To verify ,You can then choose 'c' as the source and 'Rsync' (+path to backup on external) as the destination. The 'apply' button is good and test connection should work as long as the 'host and path' are imputed correctly

My screw up here is I've tried to Restore the data back on to new disks in the Duo.
Then select 'Rsync' (backed up data off of original older disks that I'm replacing VERY DELICATE DATA) as the source
Then try to select 'c' as the destination(which the option to select 'c' is not there) to try to verify my new data on the new 'c' volume (no option to choose 'c')
So I switched the 2 around
So 'c' became the source and 'Rysnc' became the destination
Which is fine as long as there were no complications whilst restoring the data from Backup to the new disks.
If any data was missing, then I've not verified or corrected nothing.
Worse, if you had the option to 'Delete files not on Source', and actually cocked it up and reversed the procedure as described above.
Because any files missing in the new volume on 'c' on new disks on Nas/Duo would now be mirrored in your only Correct Backup from Earlier Configuration.

Therefore don't do what I described above.

If this helps anyone out, Great. If I'm the only idiot to get confused, Great, No-one else gets caught out.

As I sit here finishing this post up, and reflecting on what went wrong. ... I guess overload eh? Too many variables to work out, and the information scattered. And Yes, the fact that you can't restore the 'c' volume as a standalone procedure should be Highlighted somewhere obvious.

I haven't been to work for a week and a half, right before Christmas. But I'm glad it's over.
Anyone following my posts the last couple of weeks/today and answered my questions. I'd like to say Thankyou.

I mentioned an Rysnc guide in a couple of posts that might've needed tweaking. My apologies to the author. The guide was fine and helped me out. The problem was trying to restore/verify the 'c' volume, which as I've discussed is not an option. It just needs to be PAINTED SOMEWHERE BIG.

I got a cup of Tea and peace of mind. Except for a poxy hdd dock which caught fire today with my Backed up Data in it.

mutley, a tired dog



Note: 21st November 2011

I've just come back to read this post of mine a year later because I couldn't remember the correct settings for setting up an Rsync backup after just completing the regular backup. And basically I struggled to fathom my own scribblings, and had to go and read another thread from someone else that is included in this thread somewhere.
But here's the link for the thread I just had to re-read, for the sake of being thorough http://www.readynas.com/forum/viewtopic.php?f=31&t=47521, but the crux of my little problem is described simply below.


So just to clarify easily for anyone, here's a little note i've written to myself and kept in my documents for reference.

It's the destination for the backup that's chosen as the "Remote:Rsync Server". (in case like me you didn't have a clue whever it should be the Backup source or Backup destination).

Choose the Source as normal (STEP 1).
The "Destination selection" is the "Remote:Rsync Server" choice on the drop down selection tab for the share/destination/backup. (Basically STEP 2)
So on destination choose "Remote:Rsync Server" followed by Host (127.0.0.1), then Path (hdd/folders/...) etc...

This completely done me tonight trying an Rsync. I didn't know which was the Rysnc volume, Source or Destination. As I just plain forgotten.

Hope this helps

mutley

First post...hi :)

Last night while installing three HD204UI into my new diskless ultra 4, I came across this information:

http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks

Note this part before freaking...
The problem could not be reproduced with the above test if any of the following conditions are met:
* Disk write cache is disabled.
* NCQ is disabled. This may not always be true as the c't lab also reported problems with NCQ disabled.
* A modified test version of smartctl which does not issue IDENTIFY DEVICE commands is used. Then all other SMART and non-SMART commands used by smartctl work without any data loss.
* The disk is replaced by another model (tested with Samsung HE103UJ and Seagate ST31000524NS).

So before writing any data, I turned off write caching. Everything is going well afaik and I'm seeing about 55mb/s write speed...thoughts? Hopefully Samsung's fix will come soon...

I just learned about the HD204UI bug today as well. Can support comment on the best config to use to avoid this error?

The drive is not on the HCL so doubt support will have any advice.

I've been using 4 of these drives for several weeks without this issue. Has anyone actually had this bug happen to them?