Thanks for your detailed answer, I read all of it :-)
To make it short ...
I never thought about using more than one configuration, thanks for pointing
this out, it would  need more space, but nowadays diskspace is cheap.
Lsync sounds nice too, I have one or two offsite locations I may use for
syncing. But the warning to not use it productive scares me a little bit.
Sparse bundles as far as I know don't exist in linux . As far as I know you
could use an hfs+ volume within linux, but normally there is no real reason
to do this for a linuxuser (if he doesn't want to share a partition between
Mac and a Linux box)
I have a list of some backup programs I try to go trough and test, I hope on
weekend I have some time to start my backup.
If I have any further questions I'll post again.

Thanks again for your answer!
Greetings from Austria,

> -----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
> 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.
>  - 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?
>  - LBackup supports chained backups (for sending data off-site).
>  - LBackup supports multi-destination very well for the kind of scenario
> provided.
>  - If you have problems then please let me know.
>  - If a Mac OS X system as the backup server is a then :
>    - You gain access to sparse bundles which allow quick snap shooting of
> backup set.
> ------------------------------------------------------------------------
> Extended version :
> > Has someone tested it on Ubuntu LTS 10.04? A lot of your documentation
> deals with Mac Os and some rare pages also with debian, which is near to
> ubuntu, so I hope the best.
> LBackup has been tested with Ubuntu LTS 10.04. However, it has only been
> tested with the Ubuntu system being a backup client not as a server. It is
> very likely that this particular version of Ubuntu will work as a backup
> just fine, although to my knowledge lbackup it has not yet been tested
> this specific version of Ubuntu in this configuration.
> LBackup works on a variety of Ubuntu versions and I have not seen the .deb
> installer for lbackup fail on a Ubuntu system to date. If something goes
> wrong then please reply to this message and in the mean time refer to the
> instructions for installing lbackup from source :
> http://www.lbackup.org/source
> > Another technical question: I want to have a set of snapshots like
> rsnapshot does – 1 daily snapshot, some weekly snapshots, for older data
> only some montly snapshots, yearly snapshots … Is there a way to
> this,
> Yes, the easiest way is to have three backup configurations each with a
> different schedule and number of backups. For example, one backup config
> for daily, weekly, month and yearly.
> The advantage of this approach which at first seems counter intuitive, is
> you are able to have multiple backup sets for backup configuration being
> stored on different physical media, which may be separated geographically
> (eg. The data in different physical locations).
> In essence, this approach allows you to keep the daily backups on-site and
> the monthly backups off-site. Basically, LBackup has the ability to deal
with a
> number of different backup policy requirements. This allows you to comply
> (in some cases more easily) with your organizations backup policy.
> It is possible to configure backups to DAS every 40 min, every week, every
> month and every year. Yet, each of these sets could go to different media
> additional redundancy. It is also possible to decide on physical proximity
> your backups based upon the frequency of the backup. For instance, if you
> have a high speed network to a different building close by or on the other
> side of the city you could perform frequent backups via this network. Then
> your link to another country is slower then these backups could be
> automatically mirrored off site via a the internet at less frequent
> In addition, when the monthly backup is running (which could be a lot of
> data) the backups each 40 min will still carry on 'simultaneously'
provided you
> have sufficient disk space.
> If your data set is large then you may not want to use this approach as
> may want to be focusing on reducing the backup storage requirements.
> A post action script could compress a snapshot and like you said save it
> 'daily.0'. Such a configuration would be quick to implement as a post
> script (depending upon the complexity required).
> Currently there is no post backup script examples to perform such an
> operation, if you develop one then please consider contributing this back
> the lbackup project.
> There is a pruning command lprune which is currently in development. The
> plan is to include lprune within the lbackup installer to make removing
> backup snapshots from the backup set as easy as possible. The code to do
> this is already available within an other project developed at lucid
> lsync.
> Lprune will also make writing a post-action script to rename a folder
> than coping it a really easy. As mentioned, lprune is not available yet as
it is
> still under development. However, if you are interested in assisting or
> involved with alpha testing then please let me know. This is a feature
> will make writing a post action scripts to do what you have said (renaming
> directory) trivial to write.
> The reason the for the lprune command is that it will provide a great deal
> flexibility with regards managing the backup set. This is why the
> is not being provided as an exmaple backup post-action script.
> > Just rename the last snapshot of the day with a post action script to
> something like daily.0 and delete the older hourly backups? Would that
> anything if there is suddenly a folder named daily.0 in the snapshot
> Yes this is a possibility. Except without the lprune command it is not
> to just rename the snapshot.0 directory, you would need to copy it (with
> rsync to reduce disk usage) or as mentioned above compress the directory.
> There is no problem with having a directory called daily.0 within the
> set or even in a sub directory called daily snapshots. However, removing
> of the snapshots without re-numbering the other ones within the set
> (excluding the highest number or oldest backup) will cause lbackup to
> an error during the next execution because the backup snapshot numbers
> will no longer be consistent. The lprune command will take care of this
> and allow you to remove or rename a snapshot while keeping the snapshot
> directory in sequence.
> If you do re-name rather than copy or hard link, then you will receive a
> message upon the next lbackup run regarding an in-consistent state of the
> backup set. However, if you copy / hard link the snap shot directory
> than renaming the directory it will be fine.
> Again, if you come up with useful post actions then please consider
> contributing these to the lbackup project.
> The problem with having a backup script rather than a separate backup set
> for each is that you have less redundancy and also the minimum time
> between the shortest backups will be affected by the time it takes to make
> an additional copy of the most recent backup offsite or even on to a DAS.
> If your backup set is not massive, then purchasing additional disk space
> means you may have the snapshots on different backup servers or at the
> least on different disks which will add to the number of instances of your
> data. For example, in the event of a file system failure on the daily
> having a separate copy on an offline / online / offsite will mean that the
> is still in the weekly backups, hourly backups or yearly backups.
> In summary, using a post action scripts is possible and if you are low on
> backup storage it is probably a good approach. However, if you want to
> increase your redundancy and have available storage then backing up to
> multiple via multiple backup configurations will provide increased
flexibility in
> the long term. For example, an onsite server perfuming a  daily backup
> push the backup off site upon local backup snapshot completion. It would
> also be possible to configure the backup to be pulled offsite for added
> integrity of the data. If you use an multiple backup configurations,
> the off-site move then is far simpler because your more frequent backups
> may carry on to local disks while the offsite transfers are taking place.
It is
> even possible to have multiple versions located off site all taking
> of the hard linking via a chained lbackup configuration. For example a
> script which activates a second (third...etc) instance of lbackup. This
> is simplified if you have a access to a Mac OS X system which supports
> bundles because replicating the entire backup set with lbackup or rsync
> becomes a great option :
> http://www.lbackup.org/synchronizing_disk_images_between_machines
> Finally, if you find that any of the meta-data on your system is not
> with the current version of LBackup. I am happy to assist you with
> that within the next beta release LBackup supports your meta-data
> requirements on this version of Ubuntu.
> You may also be interested in a system called lsync which offers very
> rotation options. Further details regarding lsync are available via the
> link :  http://www.lucidsystems.org/tools/lsync
> If a system which is similar to sparse bundles exits for Ubuntu please let
> know. This would mean that the script listed via the link above (relating
> syncrhronizations_of_disk_images) will be able to be ported to LINUX and
> will be more efficient with large data sets particularly when lbackup
> is configured.
> Lucid offers professional support for both lsync and lbackup.
> If you require clarification on any of these points or just have questions
> please let me know.
> Finally, thank you very much for your feed back! I hope you have your
> backups up and running soon!
> _______________________________________________
> lbackup-discussion mailing list
> http://www.lbackup.org
> Change options or unsubscribe :
> http://lbackup.org/mailing_lists

lbackup-discussion mailing list

Change options or unsubscribe :

Reply via email to