Dokumentation of on-disk/on-tape data format

[lst_...@kwsoft.de]

Hello,

Within Bacula there is a public available documentation of the
on-disk/on-tape data layout. At the Bareos Website the following
sounds like Bareos will move away from this layout:

If you want to be able to switch back to using bacula after using a
bareos director and storage daemon you have to enable the compatible
mode in the storage daemon (which is currently the default) to have it
write the data in the same format as the bacula storage daemon.

Is this correct and will there also be a public available
documentation? What is the "roadmap" for compatibility for tape
between Bacula/Bareos?

Regards

Andreas

[Marco van Wieringen]

We currently have 2 compatible options one in the SD and one in the
FD. The compatible option in the SD currently only writes a different
tape header e.g. version 20 instead of 11 and Bareos 2.0 instead of
Bacula 1.0

From src/stored/block.h

/* Tape label and version definitions */
#define BareosId "Bareos 2.0 immortal\n"
#define OldBaculaId "Bacula 1.0 immortal\n"
#define OlderBaculaId "Bacula 0.9 mortal\n"
#define BareosTapeVersion 20
#define OldCompatibleBareosTapeVersion1 11
#define OldCompatibleBareosTapeVersion2 10
#define OldCompatibleBareosTapeVersion3 9

This is only in anticipation of any incompatibilities between Bacula
and Bareos in the future. First of all we have limited the Bacula words
to an absolute minimum as to trademark protection issues (its not our
choice that the binaries are named bareos-dir etc.) Also we never know
when Bacula takes an other direction (or will exist in its present
form what so ever in the future. Bacula Systems is very sure their
Enterprise code is not Open Source and AGPLv3 so we will drift apart
eventually so we wanted to be sure we already counter that. That is
also why we say set it to compatible if you ever want to switch back
because if we change the default you might be in for nasty surprises.

I cannot look into the future and we might take in changes from
Bacula if the happen and when they are appropriate for our code base
and add something.

As to documentation, we are working on that but it also has trademark
and copyright issues so we want to be careful there.

Also keep in mind that some particular things write their data streams
maybe in a way that the Bacula SD might understand but it can only be
restored by a Bareos SD/DIR combination e.g. NDMP is one of those examples.

Also when you disable the compatible option in your FD it will enable
some important new features but it won't be fully compatible with Bacula
anymore. Things that I know of that will happen are:

- New FD version for passibe support in 13.2.0 and later.
- Compression streams always using new compression stream
(Bacula still writes the old GZIP streams, we understand them but
if you write a new backup it will use the native compression streams).
- New compressions like LZ4, LZ4HC and LZFAST also using the new
compression streams that Bacula understands but won't be able to do
anything with as it doesn't have the support to unpack them.
- Crypto cipher, we allow you to set your crypto cipher its unknown what
happens when you restore that with a Bacula fd.
- Runscript protocol (we deprecated the old runscript protocol which
was upgraded in 2006 in Bacula but never removed.)

Hope this explains why and what is different. If you have more questions
don't hesitate to ask I will try to answer them as good as possible but
some things revolves around trademarks and copyrights and that makes a
fork of Bacula big effort.

--
Marco van Wieringen marco.van...@bareos.com
Bareos GmbH & Co. KG Phone: +49-221-63069389
http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens,
P. Storz, M. v. Wieringen