NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Fallon
Oct 15, 2010Aspirant
Spinpoint F4 HD204UI 2TB 5400 RPM working good so far
There was a recent deal at NewEgg on the SAMSUNG Spinpoint F4 HD204UI 2TB 5400 RPM 32MB drives, so I decided to risk it as opposed to the other WD & Seagate 2tb drives. I installed them, upgraded the ...
Mutley1
Nov 29, 2010Aspirant
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
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
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!