On 04/01/2012 21:52, Adrian Reyer wrote:
> On Wed, Jan 04, 2012 at 12:16:55PM +0000, keith wrote:
>> 460M Dec 29 23:19 Full-0001
>> 26.3G Dec 30 23:52 Full-0003
>> 702M Dec 24 23:05 Inc-0001
>> 10.0G Dec 30 01:54 Inc-0002
>> 2.3G Dec 31 00:06 Inc-0004
>> 3.1G Dec 31 00:56 Inc-0005
>> 611M Dec 31 00:56 Inc-0006
> Is the 10G on 24th mostly additional, changed or moved data? Are these
> compressed backups?
Hi Adrian, The 10G was just a new additional client being introduced
into the Bacula.
>
>> Now that the backups seems to be working I need to figure out how to
>> implement an offsite strategy, I want to use a combination of removable
>> disks and rsync to do this.
> I think bacula is not the ideal tool for running additional offsite
> backups. And very likely rsync is not a good way if you use bacula.
Oh ok....
>
> I have 3 possibilities in mind:
>
> 1. If you are not talking about windows clients, I'd consider using rsync
> (e.g. via rsnapshot) to run the complete offsite backup unrelated to
> bacula. Run one rsync/rsnapshot job per client and the 'new' client will
> just run longer, independent of the others except the shared bandwidth.
> Via rsnapshot you only need to do 1 full backup per client, changed
> files just lead to new full backupsets, but only the difference needs
> to be transferred. We do that on several locations and wrote a wrapper
> round rsnapshot (which is a wrapper round rsync), debian packages are
> available at
> deb http://ftp.lihas.de/debian stable main
> package rsnapshot-backup.
> If you add some file unification tool, you get away with far less used
> diskspace.
> + only changes need to be transferred
> + initial backup can easily be transferred on external media to save bandwidth
> - no bacula, no bacula indexes
> - no backup of windows clients / anything that doesn't have rsync
We have some Unix servers but the bulk of our servers are Windows.
Our old/current backup strategy is to do full backups nightly and these
are about 450G Compressed.
If I could I would like to do some type of copy jobs where I copy the
Incremental files to another place on the server and then get rsync to
down these files knowing that they were just the incrementals.
>
> 2. Alternatively you can use the normal bacula backup + a copy job.
> As copy jobs only work on same bacula-sd, you could e.g. NFS-mount some
> external server and store the target pools there. The copy full pool is
> to local disks on individual mountpoints. Move the volumes to the remote
> location and replace it with links to remote NFS.
> + works with all clients
> - regularily transporting volumes offsite is required
Only just read about "Migration / Copy" jobs last night (I am slowly
getting through the Bacula manual) and will probably try to get one of
these jobs working later today. I plan to have one dedicated bacula-fd
server and have also planned to put the removable disks (Offsite Backup)
into this server. If I can get Bacula manage my offsite disks and to
also know whats on these disk will be great.
>
> 3. Run a complete seperate job instance to the remote site using a
> bacula-sd installed there. Use virtual full backups to create the fulls
> from the full/diff/inc backups. Initially a full backup has to pass the
> remote connection.
> + works with all clients
> 0 initial full might be expensive in bandwidth
>
> Currently I use 1. and 2. myself. With 3. I ran into trouble selecting
> the correct pools in my environment and virtual full in general
> including a tape changer with a single drive.
There are network / firewall issue outwith my control that would make remote
Bacula backups an issue.
>> If I add a new server to be backed up to Bacula midweek it does a full
>> backup in the INC pool. This might be a big backup and screw-up my Rsync
>> job.
>> Does this seem like a good idea and goes anyone know how keep Full
>> backups out of the INC or DIFF pool
> Just do a manual initial full backup on the new client. As I assume they
> don't appear magically in your backup setup.
>
> Regards,
> Adrian
Your right, they shouldn't just be appearing but they are while I play
with Bacula :>) But in the future when adding new clients in then it
makes sense to manually kick off a full backup.
Adrian, thanks for the detailed answers. I give the copy jobs a try and
see how I get on.
Cheers
Keith.
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
