[lbackup-discussion] volume paths confusion

Scott Haneda reply to this message via the mailing list
Fri Aug 21 20:34:23 NZST 2009


Thanks for the reply, comments interspersed below..
* Are you aware the mailing list archives are not working?

On Aug 20, 2009, at 10:16 PM, henri wrote:

> One thing to be aware of is that LBackup is not designed for full  
> system bootable backups. Although, it is probably possible to make  
> this work it will most certainly require some custom post/pre hook  
> scripts.

I am not looking for bootable, I am just looking to clone the main  
drive to a second location.  I am cloning to a directory, which would  
never be able to be bootable.  I just want to have all the files that  
are on the boot volume, in case of catastrophe, I can either clone  
back to another source, and bless to make it bootable, or pick and  
chose what I need.

There are too many things for me, since these are servers, in /etc / 
var /opt and many other places that I would rather just copy the  
entire / and know I have it.

> The following link has details regarding alternative backup systems  
> if you are looking for a bootable backup :http://connect.homeunix.com/lbackup/about#alternatives_to_lbackup

I read that, and I am satisfied with it not being bootable at this  
time.  Even if I were to "bless" the directory, it would still not  
boot since it does not live in root of the second drive.

> If you are backing up the root directory on Mac OS X then you may  
> wish to consider the recommendations regarding disabling all of the  
> standard Mac OS 10.5 files and directories and then adding in  
> directories and files as required. Details are available from the  
> following URL :
> http://www.connect.homeunix.com/lbackup/full_system_backup

I am just not sure I want to have to constantly maintain a list, I  
would rather know that it is all being backed up.

>> backupSource="/Volumes/boot-drive"
> The backup source above is a symbolic link. LBackup would attempt to  
> backup this as a symbolic link rather than traverse the contents of  
> this link. This behavior may be altered by modifing the source code  
> or expelling why you believe the behavior should be different or why  
> there should be an option.

My mistake, I am not sure why I did not see this.  I know that is a  
symb link, for some reason I am not thinking correctly.

>> This is taking a considerable amount of time, so I suspect this is  
>> what I want.  Can I get some clarification on how this works with  
>> paths?
> Please let me know if you require any further clarification.

Yes, actually, I ran into major issues today.  Backup source was "/"  
and destination was "/Volumes/jambajuice/backups/daily"

I let it run a long time, and my remote ssh connection died. Not a big  
deal, I just tried to run it again.  lbakckup noticed it was not  
complete, and tried to recover.  I decided to just start over, and did  
a sudo rm -rf /Volumes/jambajuice/backups/daily/Section.inprogress

This took a very long time.  First I actually tried to just put the  
Section.inprogress in the trash, but it took hours to even calculate  
the number of files.

I can use CCC or SuperDuper! to clone the drive first time in a half  
hour first run, lbackup was taking much longer. (pretty fast RAID)

If I start to probe into the Section.inprogress directory, I think I  
can see what is happening.

Here is a sample path:
/Volumes/jambajuice/backups/daily/Section.inprogress/Volumes/ 
jambajuice/backups/

So, for some reason, lbackup is coping "/" and when it hits "/Volumes"  
it recurses into the second drive.  I do not think it would ever  
stop.  I think that it will continue to do so forever. Is this  
correct, or should I just let it run and it will eventually stop?

I used to just use rsyc with hfs+ patches in the past, and issue via  
cron a command to backup.  This worked, and was very fast on second  
run.  I wanted incremental, which lbackup offers, which is why I am  
trying this out.  I will use launchd this time around.

Am I doing something wrong, or is this a bug?

The sample path I am showing you above, went perhaps 40 recursion  
levels deep.  I had to wait over an hour for rm -rf to even remove  
it.  Maybe I just need to add /Volumes to the exclusion list, however,  
I have never had to worry about that in the past with rsync.

I am using the patched rsync with
-rw-r--r--  1 root  admin  24323 May 16 03:56 patch-crtimes.diff
-rw-r--r--  1 root  admin  47766 May 16 03:56 patch-fileflags.diff

However, those are only for meta data and resource data, which while  
nice to have, should not affect anything with recursion, as far as I  
know.

>> What command would I use in the shell to tell which files are real  
>> files, and which ones are just hard links off to other files?
> You can probably use the 'ls' command. I would recommend that you  
> issue the following command :
> I would recommend that you issue the following :
>
> 	"ls -la /Volumes/"
>
> This will list the long format of the "/Volumes/" directory and will  
> also list invisible files.
> Note that the "l" at the start of the line indicates a symbolic  
> link. A hard link on the other hand is slightly more difficult to  
> spot as it is not a traditional shortcut (Windows) or alias (Mac  
> OS). I would recommend the "Basic Backup Local Machine" (takes a  
> while to load) screen-cast available from the following URL :http://connect.homeunix.com/lbackup/screencasts

I watched all three screencasts, I downloaded them first since they  
tend to buffer badly.  This shows me how to backup some simple files,  
but there does not exist the Mac OS X /Volumes directory in it, for it  
to run into this recursion issue I am seeing.

> Another good reference regarding hard links is wikipedia : http://en.wikipedia.org/wiki/Hard_link

Also read that today, to confirm I was not misunderstanding anything.   
I was a little worried that these hard links may not be links, and  
real files, so I wanted to make sure before I ran a `rm` across this  
deeply nested tree.

I am curious.  If I have lbackup take for example "/Users/me/files"  
and send it to "/Volumes/backup/files"  and set it to 10 total  
rotations.  For example, only a few files change here and there, and I  
want to go back to the 8th rotation, as that is where the files I want  
are.  Most will be hard links back to the first backup.  A few will be  
new files, if they changed.

I take it that copying a hard link always copies the true source?

There is a note in the wiki post about recursion, specific to OS X as  
well.

> Keep in mind that LBackup is not designed for full system bootable  
> backups. LBackup is aimed at providing reliable user-data backups.  
> However, this is not to say that full system backup is not possible  
> with LBackup.

That is what I want, full system.  I may have kexts for a raid card,  
or /var/named and /opt/local/apache2 or /etc/postfix and a bunch more  
things I would rather just know are backed up.

I have plenty of drive space to hold 20+ rotations worth since the  
hard links take up no real space.  However, as it is now, I worry, I  
will eat away all my CPU running a recursive backup :)

> LBackup is a great way for some people to backup various changes to  
> non-user-data directories, between full system backups.

I am not sure I understand this statement.

> Finally, you may be interested in the latest (2009-August-21st)  
> alpha version of LBackup which has various additional features and  
> minor bug-fixes :
>
> http://www.lucidsystems.org/download/utilities/LBackup_v0.9.8r-alpha7.dmg

I downloaded it, but I can not find a change log.

> Should you like any further assistance or if you have any further  
> questions then please let me know.
>
> I hope this help.s

Very much, thank you.  I look forward to your reply.

-- 
Scott * If you contact me off list replace talklists@ with scott@ *



More information about the lbackup-discussion mailing list