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
