[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