DSM-G600, DNS-3xx and NSA-220 Hack Forum

greg,
I recently had a Vol1 drive fail.  My recovery procedure was as follows (with power-cycles in between each step):
1. remove bad Vol1 & good Vol2, insert new Vol1 in RHS
2. format new Vol1
3. insert old Vol2 in LHS
4. copy fun_plug script to Vol1 (I run fun_plug off USB, so all I needed was the file to call it)
5. copy data from Vol2 to Vol1

I too wish it were as simple as putting the Vol2 drive in the RHS, but alas... 'tis not.

the only tricky thing is to make sure your copy command is recursive and preserves attributes.  In order to put all of your data from the Vol2/HD_a2/ folder to the root of Vol1... you need to start in the Vol2/HD_a2/ folder and copy *.* recursively.  If you define a source directory then the destination (Vol1) will also have said sorce directory as a subdir.  <-- BTW, this is the same reason your Vol2 has a /HD_a2/ subdir instead of retaining the same root folder structure.

halfsoul wrote:

greg,
I recently had a Vol1 drive fail.  My recovery procedure was as follows (with power-cycles in between each step):
1. remove bad Vol1 & good Vol2, insert new Vol1 in RHS
2. format new Vol1
3. insert old Vol2 in LHS
4. copy fun_plug script to Vol1 (I run fun_plug off USB, so all I needed was the file to call it)
5. copy data from Vol2 to Vol1

I too wish it were as simple as putting the Vol2 drive in the RHS, but alas... 'tis not.

the only tricky thing is to make sure your copy command is recursive and preserves attributes.  In order to put all of your data from the Vol2/HD_a2/ folder to the root of Vol1... you need to start in the Vol2/HD_a2/ folder and copy *.* recursively.  If you define a source directory then the destination (Vol1) will also have said sorce directory as a subdir.  <-- BTW, this is the same reason your Vol2 has a /HD_a2/ subdir instead of retaining the same root folder structure.

Thanks!  The more I started thinking about it, this seems to be the only way to go.  I guess it's time to order that 3rd drive and just have it on hand for when one of the others fails.

From February 2008:

blbrown wrote:

Dexter Tones wrote:

I followed the tutorial and everything went smoothly. However, I was looking at the rsync FAQ and it says that one should "expect rsync to consume about 100 bytes per file" to "hold the list of files being transferred."

[...]

2. Wait until rsync (http://samba.anu.edu.au/rsync/) version 3.0 is complete and someone (fonz?) compiles it for the DNS-323.  Version 3 addresses this specific issue and it's currently in pre-release which gives me hope it will be complete some time soon.

I see that ffp v0.5 beta has a 3.0+ rsync package; does this mean the above user's hope is fulfilled and rsync is now memory-efficient enough to handle - for instance - a backup of half a million + files?

I've been sticking to fun_plug 0.4 until 0.5 leaves beta, but may upgrade sooner if it will give me the ability to do the copy without the enormous slowdown I encounter for the last 5% or so of the files on my wife's Mac Mini OSX root partition.  However, I don't see anything in the wiki or here on the forums which addresses this issue (perhaps because it probably doesn't affect very many people...) so I'm missing a term in my risk-reward calculation!

bscott wrote:

From February 2008:

blbrown wrote:

Dexter Tones wrote:

I followed the tutorial and everything went smoothly. However, I was looking at the rsync FAQ and it says that one should "expect rsync to consume about 100 bytes per file" to "hold the list of files being transferred."

[...]

2. Wait until rsync (http://samba.anu.edu.au/rsync/) version 3.0 is complete and someone (fonz?) compiles it for the DNS-323.  Version 3 addresses this specific issue and it's currently in pre-release which gives me hope it will be complete some time soon.

I see that ffp v0.5 beta has a 3.0+ rsync package; does this mean the above user's hope is fulfilled and rsync is now memory-efficient enough to handle - for instance - a backup of half a million + files?

I've been sticking to fun_plug 0.4 until 0.5 leaves beta, but may upgrade sooner if it will give me the ability to do the copy without the enormous slowdown I encounter for the last 5% or so of the files on my wife's Mac Mini OSX root partition.  However, I don't see anything in the wiki or here on the forums which addresses this issue (perhaps because it probably doesn't affect very many people...) so I'm missing a term in my risk-reward calculation!

My personal feelings are that ffp 0.5 has been in beta long enough to consider it stable.  I'll be moving to it when I get the time.  On the other hand, rsync has undergone some bug fixes since the initial 3.0.0.  Perhaps Fonz can build version 3.0.3?

I'd like to hear your experience with rsync version 3+ since you might be one of the few people that has actually seen earlier versions really bog down due to transferring so many files.

fonz wrote:

May take a few more months. Afaict, current 0.5 works as well as 0.4, maybe better. If you keep a backup of your fun_plug script, it's also easy to revert to 0.4, since 0.5 won't overwrite any of the files (except the fun_plug script).

OK, that's clear enough - no point in waiting a few more days/weeks then.  I've just had so much trouble with my -323 lately (nothing due to fun_plug of course) that I'm leery about doing almost anything these days...

blbrown wrote:

I'd like to hear your experience with rsync version 3+ since you might be one of the few people that has actually seen earlier versions really bog down due to transferring so many files.

Well actually, it was "cp -a" - started out at 5-6 megs per second (over gig-ethernet NFS) but slowed to 1-2 megs per minute after several hours, and I finally killed the job after well over a day when it had reached what I'd calculated to be roughly the full backup amount but was still creeping along.  I was only trying to create an initial backup fileset, to have *something* in place before taking the step of getting rsync set up properly for automating future backups.  I reckoned a future rsync could fill in whatever the killed job had left to do, and/or be faster recreating the full set in the first place. 

I had originally looked into the "Time Machine"-esque schemes mentioned here and elsewhere, before realizing it was a lot more capability than I wanted or could use.  So I was reading up on rsync in general, to determine which options were best for my needs (and bear in mind that with a 9-5 job, a 2-year old at home, and the wife working evenings and weekends, sometimes I have as little as 20 mins a day to futz around on the computer...)   

But I will post if/when I try it and observe anything noteworthy.

OK, I have a question.  Does the rsync folder structure behavior mimic that of cp?  Specifically, if I were to change the crontab entry to this:

/bin/echo "5 2 * * * /mnt/HD_a2/fun_plug.d/bin/rsync -rlptDv --delete /mnt/HD_a2/* /mnt/HD_b2 >> /mnt/HD_a2/fun_plug.d/log/rsync.last.log 2>&1" >> $CRONTXT

(changing the source from "/mnt/HD_a2/" to "/mnt/HD_a2/*")

then would it mirror Vol 1 to Vol 2 without the HD_a2 directory at the root of Vol 2?

The goal here would be to make recovery much faster -- just move the good backup drive from LHS to RHS and you're done.

Nurunet.... this may help you get started...

Cheers,
Chumby

vi didn't work for me, I couldn't exit it. So I created the editcron.sh with Notepad++, saved it to /mnt/HD_a2/usbstorage/, then ('cause I ain't got write permission in the ffp directory from Windows) moved it via SSH (Putty) with mv to /mnt/HD_a2/usbstorage/ffp/start/editcron.sh. Yes, I adapted the paths.

Then I chmodded the file, rebooted the NAS and after that, a crontab -l showed exactly... nothing. Not even the three tasks that should have been there anyway, if I read correctly. In the ffp.log, I found this:

/ffp/etc/rc: line 45: /ffp/start/editcron.sh: not found

It does exist. What am I doing wrong? Where are my cron jobs?

What is the easiest way to manually trigger the rsync (including logging)?   I don't always leave my box on and want to be able to manually set the backup to start.

Also, is there a way to have the log time/date stamp each line?

thanks

Last edited by 3rdparty (2008-10-05 22:10:34)

I think I messed up the vi part. I created the editcron.sh with nano, and now it works. Still, rsync is the only cronjob under crontab -l. Where are the others?

One more question. I looked at the log of the first backup operation, and it said:

sent 67446261675 bytes  received 114772 bytes  2476686.92 bytes/sec
total size is 470895637389  speedup is 6.98

Why did it receive any data? The target directory was supposed to be empty.

nurunet wrote:

Okay, I guess halfsoul explained why everything is copied to the subfolder "HD_a2" on Volume_2. Anyway, I didn't understand. I'd rather prefer to have the data in Volume_2's root. Would that be possible, and what would I have to do to accomplish that?

I haven't tried it yet to verify if it works, but you should be able to change your crontab source and destinations to "/mnt/HD_a2/* /mnt/HD_b2" to get the backup to the root directory.  Care to be a guinea pig and report if it works?

Well, I managed to move all the folders from the HD_a2-directory to Volume_2's root... except for the hidden system folders (.bootstrap and .systemfile). I didn't dare to move them manually, fearing a .bootstrap on the second drive might get me into trouble, just like overwriting the .systemfile that already existed on Volume_2 maybe could.

To cut a long story short: I chickened out. :-(

Good news though, that I could move the contents of HD_a2 with a simple

mv /mnt/HD_b2/HD_a2/* /mnt/HD_b2/

(IIRC). It only took a moment.

Maybe I'll have the guts to try this anyway next weekend, but as I've got nearly 500 GB of data on my disks, I'd hate to mess with them too much...

Last edited by nurunet (2008-10-21 00:11:52)

I figured it out,  here is what I did.

 crontab -e

That brought up vi.  Then hit 'a' to enter edit mode, tab down and change the rsync job that was scheduled to run at 2:05am to run at 4:05pm.

 
32 2 * * * /usr/sbin/rtc -s
30 2 2 * * /usr/sbin/rtc -c
59 1 * * * /usr/sbin/daylight &
5 16 * * * /mnt/HD_a2/ffp/bin/rsync -rlptDv --delete /mnt/HD_a2 /mnt/HD_b2 >> /mnt/HD_a2/ffp/log/rsync.last.log 2>&1

The 5 16 is what tells it to go off at 4:05pm

You then hit 'esc' to exit edit mode and then ':wq' to save and exit.

Run 'crontab -l' to check the time was changed and you are good to go.

Last edited by BobbyCarbn (2008-10-22 08:07:09)