[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] backup to removable external disk

On Wed, 2008-09-10 at 21:58 +0200, Kern Sibbald wrote:
> On Wednesday 10 September 2008 20:01:59 Peter Sjoberg wrote:
> > On Mon, 2008-09-08 at 14:51 -0400, Dan Langille wrote:
> > > See also:
> > >
> > > http://tregnago.blogspot.com/2008/09/bacula-with-usb-disks-vchanger-alter
> > >ed.html
> >
> > This script definitely looks like the path to take. Did a quick trial
> > implementation and it works as documented - it's just that I need
> > something a little different.
> >
> > Biggest issue is that this script handles a single USB connection (per
> > storage device) and I want to use two. Each disk is considered one
> > magazine filled with a pile of tapes and I have to change that
> > "magazine" now and then to avoid it filling up (or when it complains
> > that it's full).
> >
> > Looked at disk-changer script and a quick glance it seems to do
> > something similar, talks about diskfiles as slots.
> One note about disk-changer is that it is officially supported with Bacula 
> because it is *very* heavily used in our regression tests both for disk tests 
> and for our virtual tape tests.  We know it works.
Always good to know when troubleshooting issues

> The functionality of disk-change is probably a bit less than the vchanger 
> script you mention because disk-changer does not have the notion of a 
> magazine.
Things I like about vchanger (+autofs & udev) is that some tasks get a
little more automated/autodiscovery. No manual tasks for barcode file,
disk mounts etc.

> I have never used disk-changer in a production environment, but if I were 
> re-implementing the system documented in the manual in the "Automated Disk 
> Backup" chapter (which is by the way still running), I would use the 
> disk-changer script.
Did read "Automated Disk Backup" a bit and I want to do almost the same
but do have offsite storage requirement.

> >
> > I will think about it a bit but the way I feel I want it done is to have
> > another level between and the easiest way to do that is probably to move
> > everything up one level.
> > I have single "drive" that has a "magazine" with two "slots"/"tapes".
> > Then each tape is really a physical disk with one big file on it.
> > This way, when one disk/tape is filled up it should automatically move
> > to next tapedisk and at some point I can replace the filled tapedisk
> > with an empty one.
> > One issue I see with this is that I would end up having a single 1T file
> > on each disk and I don't think that's to good so I'm still open for
> > suggestions.
> The advantage of the "Automated Disk Backup" chapter scheme, or the vchanger 
> script, or disk-changer script is that each volume has a maximum fixed 
> reasonable size. 
A physical disk is always a max fixed size, problem is to control the

> With the virtual changer scripts, you simply create as many 
> Volumes you want each in a different slot, and limit them to some maximum 
> size.  Bacula will then manage them.  If you setup a prunning algorithm as 
> described in the "Automated Disk Backup" chapter, it then automatically 
> manages everything. 
That's another issue for me with a single huge file, pruning would be
done only when the whole 1TB is to old and that might be a while.

> Life becomes a bit more difficult if you want to swap out USB drives.  
That's the way I plan to implement offsite storage
(in reply to a comment that USB is slow.) I know USB storage isn't as
fast as internal disk (and doesn't support S.M.A.R.T) but I don't
compare it to internal disk, I compare it to DLT tapes and then it's a
lot faster.
My network is all 100MBit so that will still be the big limitation.

> In that 
> case a virtual changer such as vchanger that has a concept of magazines may 
> be useful.
> Also, you should know that if a File device is marked as removable, Bacula 
> will search the device looking for Volumes.  In theory, if you configure 
> Bacula correctly, you can just plug and unplug USB devices (providing Bacula 
> is not writing to one) at any time, and Bacula will figure out what Volumes 
> are available.  This has never been extensively tested though.  This only 
> works if you are doing something like the "Automated Disk Backup" and not 
> using one of the virtual autochangers.
Might simplify things a little, enable removable media and define all
disk partitions as in the system all the time.
One option to not get a 1T file is to make a pile of reasonable sized
partitons on the usb drive and enable "removable media" but that would
of course need thinking and testing.

On the good news list my plan is to implement this on a new server and
run both backups in parallel until I feel comfy that it works with disk
backup for offsite storage also. This way I can fiddle around without
breaking my current backup.


Attachment: signature.asc
Description: This is a digitally signed message part

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
Bacula-devel mailing list

This mailing list archive is a service of Copilot Consulting.