Hi!
> -----Ursprüngliche Nachricht-----
> Von: lbackup-discussion-boun...@lists.connect.homeunix.com
> [mailto:lbackup-discussion-boun...@lists.connect.homeunix.com] Im
> Auftrag von henri
> Gesendet: Dienstag, 18. Jänner 2011 11:43
> An: lbackup-discussion@lists.connect.homeunix.com
> Betreff: Re: [lbackup-discussion] Some beginner questions (OS & backup
> rotation)
>
> This reply is quite long. As such a very brief summary is provided at the
start.
> However, I would recommend that if you are going to use LBackup that you
> read the entire email so that (hopefully) the advantages and disadvantages
> are clear.
>
> Summarized version :
>
> - LBackup will work on Ubuntu.
I found some time last week to test lbackup on my Ubuntu LTS 10.04 as a
backup-server:
The deb-Package installs just fine, besides it drops a ._.DS_Store and a
.DS_Store in my root-dir and the /lbackup is not necessary, but it links to
/etc/lbackup, so thats ok and this is in my opinion the better place to be
Linux-FHS-compliant.
Lbackup also runs on my system without problems (at least it didn't say
there is a problem) ...
The metadata preservation is ok, as far as I can confirm (I don't use ACLs,
just "normal" Linuxbehaviour)
> - Do not move any snapshots. Instead copy or archive them (compression is
> optional)
> - No example script is included with LBackup yet.
> - If you develop one please contribute it back to the project.
> - LPrune is an LBackup component. It is still under development.
> - If you are interested in assisting with development let me know.
> - LSync is a solution which may be closer to what you are looking for?
I wanted to try it, installed rubygems and then typed "sudo gem install
lsync" - this is the error-message:
Building native extensions. This could take a while...
ERROR: Error installing lsync:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.9.1 extconf.rb
extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)
from extconf.rb:1:in `<main>'
Gem files will remain installed in
/var/lib/gems/1.9.1/gems/termios-0.9.4 for inspection.
Mkmf is unknown to my system, it suggests xmkmf or jmkmf, don't know if one
of these could work.
> - LBackup supports chained backups (for sending data off-site).
> - LBackup supports multi-destination very well for the kind of scenario
you
> provided.
I think I will take backups locally on my fileserver and then transfer this
data over rsync or lsync ...
> It is even possible to have multiple versions located off site all taking
advantage
> of the hard linking via a chained lbackup configuration. For example a
post
> script which activates a second (third...etc) instance of lbackup.
I don't know if I understand you correctly with this "chained
configuration".
Do you mean:
I have a monthly backup with lbackup locally which calls another lbackup
instance which transfers this local backup to off-site?
Am I correct?
> - If you have problems then please let me know.
No real problem, but still some questions:
1. I've also tried "Back in Time" (BIT) as an alternative, BIT saves
metadata (permissions/user/groups) in an extrafile in the event metadata
changes on the backup (I know should be readonly when if you want to gain
access to and shouldn't therefore happen). Does lbackup provide something
similar?
2. I noticed significant differences in speed between BIT and lbackup: For a
set of 23Gb I needed 69mins with lbackup, but only 24mins with BIT. Both
programs use rsync and hardlinks, and it was the first backup for both
programs. What could lead to this big difference? Some hashing, something
else?
Thanks again,
Harald
_______________________________________________
lbackup-discussion mailing list
http://www.lbackup.org
Change options or unsubscribe :
http://lbackup.org/mailing_lists
