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: li...@lihas.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
