>
> Disclaimer: I am a user, not an official developer.
>
> I've been thinking along the same lines, but have not come up with a
solution
> I like.
>
> I have thought about this one, but the problem is the
> differentials/incrementals will still be based on it. Which causes
problems if
> say you only want to keep those jobs for 3 weeks, but the on site
backups can
> be kept for much longer.
I only use Incrementals so it isn't a problem, but yes, for
Differentials it would be a problem.
>
> This is just a symptom though of the bigger issue where Bacula is not
designed
> at the moment with the concept of offsite backups in mind. Hacks
accomplish
> it, but it requires a good bit of workaround (duplicate jobs,
duplicate
> filesets, etc)
>
> The best I have come up with is an option to have the name of a job be
changed
> upon completion via scripting or similar, and ensure that all tree
logic
> restricts by job name (Most of it does, but there are a few places you
have to
> tweak in code to accomplish this).
>
> I am in the process of implementing the above, but not there yet,
mostly
> because I am stalled waiting for SAN access so that I may do full
backups to
> disk instead of the juggle imposed due to the requirement of different
pools /
> storage devices (yet not supporting separate SD's).
>
> Let me know if you want to collaborate on patches. =)
>
I think bacula needs the concept of a 'source pool' for a job. You'd
need to be able to list multiple pools for it to be useful though. One
idea I had was to be able to tag pools with one or more arbitrary tags.
Some examples of a tag might be 'Onsite', 'Offsite', 'Archive', 'Tape',
and 'Disk'. You'd then be able to specify a list of pools and/or tags
for a Job (and override in the schedule). Eg:
Pool {
# local disk pool for Full backups
Name = Full-Disk
Source Tags = Disk | Onsite
...
}
Pool {
# local disk pool for Incremental backups
Name = Incremental-Disk
Source Tags = Disk | Onsite
...
}
Pool {
# local disk pool for Differential backups
Name = Differential-Disk
Source Tags = Disk | Onsite
...
}
Pool {
# USB Removable disk - stored offsite when not in use
Name = Disk-Offsite
Source Tags = Disk | Offsite
}
Pool {
# LTO Tape - stored offsite when not in use
Name = Tape-Offsite
Source Tags = Tape | Offsite
...
}
Job {
...
Source = Onsite
...
Schedule = MySchedule
}
Schedule {
Name = "MySchedule"
Run = Level=Incremental Sources=Onsite sun-sat at 12:00
Run = Level=Incremental Sources=Onsite sun-sat at 15:00
Run = Level=Differential Sources=Onsite sun-fri at 21:00
Run = Level=Full Sources=Onsite sat at 21:00
Run = Level=VirtualFull Sources=Onsite Pool=Tape-Offsite mon-fri at
21:01
}
So only Pools tagged with Onsite would be selected as the base job for
the Incrementals and Differentials. Sources= would maybe allow you to
specify both Source Tags and Pool resources.
This could be further extended to doing restores too. You can already
specify a Pool I think, but being able to specify a Tag would limit the
source media to only (say) Onsite pools.
Next Pool would go away, maybe.
Obviously the user is quite free to engineer an unworkable configuration
(eg Level=VirtualFull Source=Onsite Pool=Full-Disk) which could cause
bacula to try and read and write from different media on the same
storage device and deadlock, but I don't think that alone is reason to
shoot down this idea (I'm sure there will be plenty of those :)
Comments?
James
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
