Hi, 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, Harald > -----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. > - 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 you > 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 the > 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 server > just fine, although to my knowledge lbackup it has not yet been tested with > 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 accomplish > 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 that > 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 for > additional redundancy. It is also possible to decide on physical proximity to > 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 if > your link to another country is slower then these backups could be > automatically mirrored off site via a the internet at less frequent intervals. > > 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 you > 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 as > 'daily.0'. Such a configuration would be quick to implement as a post action > 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 to > 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 called > lsync. > > Lprune will also make writing a post-action script to rename a folder rather > 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 being > involved with alpha testing then please let me know. This is a feature which > will make writing a post action scripts to do what you have said (renaming a > directory) trivial to write. > > The reason the for the lprune command is that it will provide a great deal of > flexibility with regards managing the backup set. This is why the functionatly > 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 break > anything if there is suddenly a folder named daily.0 in the snapshot folder? > > Yes this is a possibility. Except without the lprune command it is not possible > 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 backup > set or even in a sub directory called daily snapshots. However, removing any > of the snapshots without re-numbering the other ones within the set > (excluding the highest number or oldest backup) will cause lbackup to report > an error during the next execution because the backup snapshot numbers > will no longer be consistent. The lprune command will take care of this issue > 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 rather > 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 backup, > having a separate copy on an offline / online / offsite will mean that the data > 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 could > 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, perform > 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 advantage > of the hard linking via a chained lbackup configuration. For example a post > script which activates a second (third...etc) instance of lbackup. This process > is simplified if you have a access to a Mac OS X system which supports sparse > 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 preserved > with the current version of LBackup. I am happy to assist you with ensuring > 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 flexible > rotation options. Further details regarding lsync are available via the following > link : http://www.lucidsystems.org/tools/lsync > > If a system which is similar to sparse bundles exits for Ubuntu please let me > know. This would mean that the script listed via the link above (relating to > syncrhronizations_of_disk_images) will be able to be ported to LINUX and > will be more efficient with large data sets particularly when lbackup chaining > is configured. > > Lucid offers professional support for both lsync and lbackup. > > If you require clarification on any of these points or just have questions then > 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 http://www.lbackup.org Change options or unsubscribe : http://lbackup.org/mailing_lists
