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?
> 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.
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
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
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.
> 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
--
LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart
Fon: +49 (7 11) 78 28 50 90 - Fax: +49 (7 11) 78 28 50 91
Mail: lihas AT lihas DOT de - Web: http://lihas.de
Linux, Netzwerke, Consulting & Support - USt-ID: DE 227 816 626 Stuttgart
------------------------------------------------------------------------------
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
|
