Hi,
I'm just going through my old mails, so sorry for the late reply...
07.10.2009 00:04, Jayson Broughton wrote:
> So here's one for the list!
>
> Recently, due to file storage space, management has decided that each
> client (desktop machines) will have 1 full backup done once a week.
> This is more for Disaster Recovery (DR) than retrieving data from a 'oh
> I lost my file) client.
>
> Here's the layout:
> *~200 clients in the building
> *We figure we can split the clients geographically (East, West, etc)
> into Pools that are by the Day of the week. ex) Pool 1 = monday, pool 2
> = tuesday......
> *Now each pool would (yes, you guessed it!) back up on that said day.
> For servers, this wouldn't be a problem, as servers don't pack up at the
> end of the day and go on vacation for 2 weeks.
> *I can migrate the Full backup from Disk to Tape the day before the full
> backup kicks off (thus having a tape copy in case someone is actually on
> vacation and their machine hose's)
>
>
> Now here's my problem.
>
> As these are clients, including a vast mix of laptops, I can set a
> reschedule interval and reschedule time for a 24 hour period so that
> they can attempt to back up in a 24 hour period. But, does a migrate
> job (yes I have read the install/configuration/developers manual) allow
> to migrate 35 volumes (if I set 1 volume per job) into 1 tape volume?
Jup. Migration works on a Job-by-Job-basis, so you essentially don't
migrate volumes to another storage device, but jobs to a new volume.
And of course you can specify the target pool to put as many jobs or
bytes on a volume as you like. For tapes, you'd probably not limit it
artificially at all.
> I thought about having 35 clients backing up to 1 disk volume, but
> that's around 75GB+ per volume, which would significantly increase seek
> time on trying to do a restore.
If I understand the current state of Bacula correctly, that shouldn't
be an issue any more. But I'd still advise smaller volumes...
> I could do 35 volumes (1 volume per
> job) but my main worry is that if I set volume retention on the Pool
> resource to 7 days, then anyone that didn't get backed up, that didn't
> migrate to tape would lose their data. If I set it any higher than 7
> days of retention then we double the space on our storage server.
True... chose your poison :-)
> Yes, I know, things would probably be easier if we had more space,
> bigger drives, etc. But I have to work with what I have available to
> me. Previously we were doing 2 week backups of pools (2 fulls, 8
> incremental's), then because of space issues..we went down to 1 week
> backups (1 full, 4 incremental's)..and now 1 full once a week.
>
> If I could get this to work without overwriting the volumes, or growing
> volumes, before the migration gets sent to the tape, then this would be
> awesome.
I'd start with a setup where you make sure each client backup job uses
its own volume (Maximum Volume Jobs = 1) and then tweak the pruning...
Add in a specific pool for full backups, so you can prune incremental
backups automatically (I assume that keeping full backups will be
sufficient).
You might end up doing the pruning semi-manually, in that case... A
script to check which clients had a full backup each week and then
prune old full backups of only those clients. The full backups of
clients not backed up would remain.
When migrating to tape, simply migrate (or, even better IMO) copy all
the full backups that are still on disk, and you should be close to
what you need - if I understood you correctly :-)
Cheers,
Arno
>
>
> ~Jayson
>
>
>
> The information in this electronic mail message and any attached files is
> confidential and may be legally privileged. If you are not the intended
> recipient, delete this message and contact the sender immediately. Access to
> this message by anyone other than its intended recipient is unauthorized.
> You must not use or disseminate this information as it is proprietary
> property of the True companies. Communications on or through the True
> companies' computer systems may be monitored or recorded to secure effective
> system operation and for other lawful purposes. Thank you.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> 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
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
