Hello,
first, this discussion might be placed better at bacula-devel. If you
intend to do some development, you should subscribe that list, too.
I'm cc'ing -devel, by the way.
On 1/7/2006 6:24 PM, Jason Gillis wrote:
Hi all,
I've been using bacula for a few months now (at home) and have been
quite happy with it so far. (Thanks to the developers that have put so
much work into this system.) To date, I've mostly been doing nightly
backups of a couple systems to disk, which are then manually moved to an
external USB drive.
I've been working with bacula this week to try to get backups to DVD
working (both DVD+RW and DL DVD+R). I have about 100GB of data that I
want to put on DL DVD+R so I can have some longer term storage than the
existing disk-based system I have.
After struggling for a week, I think I've run into the problems that
most people have (based upon my googling up information to try to figure
out why things don't work for me), and have gotten past some of them.
Nice to hear...
The big problem that remains is the issue of how DVDs are utilized by
bacula, due to the limitations of the tools involved.
0) A standard DVD+RW seems to hold about 4.4 GB, some of which I would
guess is going to get eaten up by overhead. The DL DVD+R comes in at
around 8.1 GB, minus whatever overhead will be.
1) The largest file that mkisofs seems to want to write to a DVD is
about 4 gigabytes. (This is a problem with mkisofs, as it doesn't issue
an error when a file is skipped. I was quite confused when my 4+ GB
part files didn't appear on disk although dvd-handler had run. Bacula
thought the data had been written correctly, too. I've looked briefly
to see if there's a flag in mkisofs that makes it error properly when it
can't do something but I didn't see it.)
Hmm. I've never tried putting that large part files to a DVD, but from
my experience I'd say that growisofs / mkisofs report correctly when
they can't do something. The problem might of course be in dvd-handler.
And right, there is a size limit for part files inside Bacula. See the
corresponding manual section.
When you limit the part size, you avoid trying to write too large files
on a DVD.
2) Bacula seems to want to only write to an empty DVD or to a DVD that
has only a zero length file with the current volume's name.
Definitely not always true - I know for sure that Bacula can write
multiple part files sequentially to one DVD. I've done it, and I've
implemented part of the code :-)
Recognition of a writable DVD can be much improved, though.
I think that #1 and #2 are at odds with each other. Removing either
limitation would make DVDs much more useful. If there weren't a 4GB
size limit on writing to DVDs with mkisofs or if bacula would write to a
non-empty DVD, then, in my mind, DVD writing would be much more useful.
I think that the 4GB limit is a harder one to get around because it
appears to be an issue with the ISO9660 file system used, so I've
pondered what might make bacula do this better...
Use part files...
In my explorations, I've poked my nose through some of the storage
daemon source code relevant to DVD writing. I've had the following
thought:
What happens if check_can_write_on_non_blank_dvd() does something
different? That is, I'm thinking that this function could be more of a
check_can_add_new_session_on_non_blank_dvd() function. Such a function
would check to see if the DVD is available to be written to as another
session (e.g. 'growisofs -M'). If it returns true, then bacula should
just write another part file to the next session. This would result in
better utilization of the DVD disk.
The current function works well enough, but only if you're writing a
part file to the DVD that is close to it's capacity. If you write a 1gb
part file to the DVD, you're going to be very sad when you realize that
you could hold 3 more parts, but bacula just doesn't want to do it.
When using a larger media (DL DVD), it seems that you're really quite
stuck.
I'm going to try to spend some of my free time implementing this idea,
but I did want to check with folks to see if this makes any sense at
all. (I think that knowing the reasoning behind not allowing a DVD to
have more than one volume file is key here.) Maybe bacula already does
all this stuff and I just haven't found it yet?
At least, Bacula does part of that.
Personally, I'd prefer to see more of the functions you mention in
external scripts - the original dvd-handler, with its OO-architecture,
was designed around that idea.
The basic idea is to implement a number of functions to
- check if a disk is suitable for writing at all
- check whih volume is stored on a disk
- blank (prepare) a disk
- label a disk
- write a part file to a disk or issue a return code allowing the SD to
request another disk and then retry,
- mount and verify a disk during restore
Obviously, there's only a small part of this concept available now, but
if you're willing to spend some time trying to get DVD writing working,
I'd like to see that my ideas are taken into consideration... see you on
bacula-devel, right? :-)
By the way - there are others interested in improving dvd-handler,
especially concerning support of DVD-RAM. I'd seriously recommend to
first discuss the future development so that there aren't several
incompatible handler scripts in the end. Currently, the SD-internal
interface to the external script is, I suppose, far from optimal. (Kern
considers the whole stuff still beta, and I guess you know why ;-)
Personally, I think that during the next few releases, it's likely that
external writer script support will have a good chance of modifying the
internal API, but once there is a larger group of people using that in
production, it's becoming less likely that the SD will be changed with
respect to the needs of external scripts. External scripts, on the other
hand (and in my personal opinion) are the best way to support
low-performance storage media.
Arno
Thanks,
Jason
-------------------------------------------------------
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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
