Hello,
22.09.2008 21:38, Robb Wagoner wrote:
> I want to send the monthly full backups off-site for DR purposes. I
> also need to keep an on-site copy of the full backups on-site in the
> event of non-DR restores.
Good idea.
> My thoughts are to use either:
>
> 1. bcopy. Keeping track of the tapes that are used for full backups
> and which of those have been duplicated.
bcopy can be a bit trick IMO. It's not as thoroughly tested as the
core of Bacula (no automatic regression testing, as far as I know). I
never really used it, though.
> 2. Migration. Full backups are written to an Off-Site Pool and
> migrated to an On-Site Pool.
The disadvantage is that a migrated job is only present on the target
volume as far as Bacula is concerned. The actual data is not deleted,
but it's no longer useable for restores without some catalog tweaking.
> I don't have adequate disk space to make one of the pools file-based,
> which means that for either 1., or 2., I won't be able to run any
> other jobs while the duplicating process (Migration or bcopy) is
> running as both tape drives will be in use.
>
> My inclination is to use Migration:
>
> * Pool "Offsite" with 6 month retention period; "Volume Use Duration"
> of a several days so that the jobs on a partially used tape are
> migrated; "Next Pool" = "Onsite"
> * Pool "Onsite" with 1 month retention period
> * Full backup jobs use pool "Offsite"
> * Migrate jobs from "Offsite" to "Onsite"
> * Set Migration job priority lower than backup jobs so that they are
> effectively done when nothing else is going on.
Sounds reasonable, basically.
> I will then have to create a custom SQL query (query.sql) to
> determine which tapes that are in pool "Offsite" & in the library &
> have been fully migrated. These are the tapes that are ready to be
> sent off-site.
The query itself shouldn't be too complicated.
>
>
> I am wondering what others do for this. . .
Well, until job cpies are fully implemented in Bacula, what I tend to
do - or rather, advise to do - is doing full backups twice. The
downside is that this doubles the load on the machines backed up, and
it can take too long for your backup windows.
The advantage is that you can use the jobs for restores without any
tweaking.
Just keep in mind that, if you use the same job setup, you must run
the offsite backups before the onsite ones, so that later differential
and incremental jobs will reference the onsite job. Otherwise, you'll
regularly need the offsite volumes for restores...
Sample schedule:
- Full job for offsite on Friday 22:00, pool offsite
- Full job for onsite on Saturday 12:00, pool onsite
- differential / incremental jobs for onsite during the weekdays, pool
onsite. These jobs will refer to the latest full job, i.e. the onsite
ones.
You can then, on Monday, just take all the used offsite pool volumes
and ship them.
Arno
> Thanks,
> Robb
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
