Personally, I don't think it's necessary for bacula to listen on dbus or
do anything fancy. I have devices setup in bacula-sd.conf as such:
#---- Storage on NFS mount s1.local.lan:/bacula
Device {
Name = s1nfs
Media Type = File
Archive Device = /net/s1.local.lan/bacula
LabelMedia = yes;
Random Access = yes;
AutomaticMount = yes;
RemovableMedia = no;
AlwaysOpen = no;
}
The SD is running Fedora Core 4 with udev and AutoFS configured to
automount NFS shares at /net/machine.name/sharename. The related Storage
config in bacula-dir.conf is:
Storage {
Name = s1storage
Address = 192.168.1.3
SDPort = 9103
Password = "somelongpassword"
Device = s1nfs
Media Type = File**
}
Notice this config is identical to using File storage on a local drive,
only the storage is really on another machine and accessed through NFS.
There is no mount command, no run-before script, or anything else
defined in bacula. AutoFS is mounting the NFS share when the SD attempts
the open(). Then when the SD closes the volume (file), AutoFS will
automagically umount the NFS share and unlink the mountpoint after a
predefined time-out. In the case where AutoFS cannot mount the share,
(ie. when I shut down the NFS server on machine s1.local.lan on
purpose), the SD's open() will get a ENOENT, fire off a "cannot find any
appendable volumes" error, and wait. Eventually the job will be canceled
if the NFS server remains down long enough.
So far, bacula works like a charm when accessing NFS shares using
AutoFS. Naturally, the share directory on the remote machine must have
permissions set to allow the SD user read/write access. Should also be
possible with SMB/CIFS shares if the AutoFS config mount options can get
the login credentials passed to mount_smb/mount_cifs or whatever they're
called. I would assume it would be similar to setting up SMB/CIFS mounts
in /etc/fstab.
I would think the same method will work for USB drives. One would setup
udev rules to assign a particular device node to a particular USB drive.
Then AutoFS is configured to map particular mountpoints to the devices
nodes that will be created by udev whenever those USB drives are plugged
in. Then when anything under those mountpoints is accessed, AutoFS will
determine if the associated device node exists. If it does then AutoFS
will create the mountpoint, mount the device, and the SD won't know the
difference. If AutoFS fails to mount the device for any reason, (say the
drive is not plugged in), then the SD's open() will get a ENOENT and the
job will be queued awaiting an appendable volume. When the SD is
finished the device will be umount'd after a period of inactivity and
the device can be safely unplugged.
So long as the SD continues to periodically try to open an archive on
the missing USB drive while it is "waiting for an appendable volume", it
should be possible to continue the job by simply plugging the USB drive in.
I don't know what happens when the drive is unplugged WHILE the SD is
accessing it. I asume it gets an i/o error and fails the job just as if
there were a disk drive failure.
--- Josh Fisher
Kern Sibbald wrote:
On Monday 06 February 2006 20:13, John Demme wrote:
So the requires mount option and family have very misleading names. In my
not-so-humble opinion, the correct way to implement removable hard drive
backup is to rename the current options to something like dvd mount ...,
and use the generic names for a generic mount/umount scheme. That is,
requires mount = yes tells the SD that it is in charge of
mounting/umounting a device. Mount Command is the command it runs to mount
the device, and unmount command is the command that SD uses to unmount the
device. Make write part command and free space command optional. Use the
output from something like df for free space by default. Then, people can
implement their hard drive backup schemes however they'd like. Personally,
I'd use something like:
Requires Mount = Yes
Mount Point = /mnt/backup1
Mount Command = /sbin/mountBackup1
Unmount Command = /sbin/umount /mnt/backup1
Where /sbin/mountBackup1 is a script that reads the drive and mounts the
first partition to /mnt/backup1, and if the disk doesn't have a first
partition it assumes it's a clean disk and writes a partition table and
creates an ext3 partition, then mounts it.
This seems to be the most straight forward way to do it
From a quick look at what you wrote, it looks like this is how I implemented
the removeable filesystem code in 1.39.5. However, I have not renamed any
directives, which would cause a lot of user pain.
and I'm a little surprised it doesn't exist already.
I'm not surprised -- there is just too much to do.
Without it, I'm just going to create
two scripts that manage the drive's mounted status and the user will have
to do it manually.
I suppose the only wrikle is detecting when a new drive has been inserted.
Preferably, Bacula would listen on dbus for a particular (configurable)
message, and the user (again) care take care of it.
Bacula doesn't do anything fancy like listening on dbus. It simply opens the
file when the job runs applying any user specified options (e.g. mount) in
the process.
I'm pretty busy right now (and my that I mean the last few and upcoming
years), but when I get a chance (hopefully later in the week) I'll grep
through the Bacula source. No promises.
Thanks for the quick (albeight disappointing) answer,
John Demme
On 2/6/06, Arno Lehmann <[EMAIL PROTECTED]> wrote:
Hello,
On 2/6/2006 4:20 PM, John Demme wrote:
I'm trying to get Bacula to backup to my removable SATA hard drive. I
want bacula to manage whether of not the drive is mounted. Thus, I
have the following bacula-sd device area:
Device {
Name = FileStorage
Media Type = RemovableFile
Archive Device = /dev/sdg1
oh oh...
Requires Mount = yes
Mount Point = /mnt/backup1
Mount Command = "/bin/mount /mnt/backup1"
Unmount Command = "/bin/umount /mnt/backup1"
Write Part Command = "/usr/bin/true"
LabelMedia = yes; # lets Bacula label unlabeled
media
Random Access = Yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = yes;
AlwaysOpen = no;
}
However, when I try to label the drive the following hits me:
*label
Using default Catalog name=MyCatalog DB=bacula
Automatically selected Storage: File
Enter new Volume name: Daily001
Defined Pools:
1: Daily
2: Monthly
Select the Pool (1-2): 1
Connecting to Storage daemon File at sophy:9103 ...
Sending label command for Volume "Daily001" Slot 0 ...
3910 Unable to open device "FileStorage" (/dev/sdg1): ERR=The media in
the device "FileStorage" (/dev/sdg1) is not empty, please blank it
before writing anything to it.
Label command failed for Volume Daily001.
Do not forget to mount the drive!!!
So I guess Bacula thinks I'm backing up to a DVD or CD since I'm using
the requires mount = yes option.
What am I doing wrong?
You can't achieve what you want like this.
The requires mount options and related stuff heavily depend on the write
part command program, so first, you'd need a real program that does what
dvd-handler does with DVDs - writing part files to the device, mainly.
Unless you're ready to read through the SD code - especially the parts
regarding DVD writing - and creating a customized write part command
program, what you want to do is not easily possible.
There have been some suggestions as to how effectively use removable
hard disk storage recently, you might want to search the archives for
these. Also, Kern has started thinking about how to handle removable
disks, so it might be that he comes up with something some day.
And, of course, you can always suggest how Bacula should handle this
sort of stuff, and also submit code :-)
Arno
Thanks,
John Demme
--
IT-Service Lehmann [EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
