How to extract data from a volume

[Ramil]

Hello
Are there any ways to extract data from a backup volume if the Bareos server is unavailable, there is no backup of it, there is no access to the catalog, database, bootstrap file, etc., but there is access to the storage? The volume is not encrypted

[Andreas Rogge]

Am 17.09.25 um 12:12 schrieb Ramil:

If you still have the storage daemon configuration (or can create a
compatible one) you can use the storage tools. In your case especially
"bls" to list the volume contents and "bextract" to extract the data.

However, these tools great to extract files and directories, but cannot
handle plugin data. If you need to extract data backed up with a plugin,
you need a full bareos installation and then use "bscan" to import the
volume.

Best Regards,
Andreas

--
Andreas Rogge andrea...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221-630693-86
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, Jörg Steffens, Philipp Storz

[Ramil]

Thank you for your reply.
So, if I don't have a storage daemon configuration, I won't be able to extract data from the volume? That's very inconvenient. It would be nice to improve the data extraction capabilities without depending on the Bareos system.

Best Regards

среда, 17 сентября 2025 г. в 17:47:32 UTC+6, Andreas Rogge:

[Spadajspadaj]

On 9/17/25 13:47, Andreas Rogge wrote:
> If you still have the storage daemon configuration (or can create a
> compatible one) you can use the storage tools. In your case especially
> "bls" to list the volume contents and "bextract" to extract the data.
>
> However, these tools great to extract files and directories, but
> cannot handle plugin data. If you need to extract data backed up with
> a plugin, you need a full bareos installation and then use "bscan" to
> import the volume.
>

A side question - does that mean that you won't be able to extract
plugin-backed data at all or is it just that it will be in a relatively
unusable format?

For example - some of my fds just write a list of installed packages as
one of the backed up resources. It's a straightforward text stream. I
don't necessarily need a plugin to have use for this sort of data. I can
get the contents and do "dnf install" manually.

[Andreas Rogge]

Am 18.09.25 um 09:26 schrieb Spadajspadaj:

> A side question - does that mean that you won't be able to extract
> plugin-backed data at all or is it just that it will be in a relatively
> unusable format?

You need a real FD to run plugins. Tools like bextract will just skip
the plugin data streams.

[Spadajspadaj]

On 9/24/25 10:36, Andreas Rogge wrote:
> Am 18.09.25 um 09:26 schrieb Spadajspadaj:
>> A side question - does that mean that you won't be able to extract
>> plugin-backed data at all or is it just that it will be in a
>> relatively unusable format?
> You need a real FD to run plugins. Tools like bextract will just skip
> the plugin data streams.

Ahhh. OK. I suppose by fiddling with the source one could make bextract
_not_ skip the data stream and save it into a file. But this is way more
work than setting up a FD on the side and restoring the data.

And does it matter _what_ plugin the data is from? I mean, could I just
set up FD with a simple "cat > file" plugin (of course it's a bit of a
oversimplification but you catch my drift) and restore raw data from
another plugin?

MK

[Andreas Rogge]

Am 18.09.25 um 07:38 schrieb Ramil:

> Thank you for your reply.
> So, if I don't have a storage daemon configuration, I won't be able to
> extract data from the volume? That's very inconvenient. It would be nice
> to improve the data extraction capabilities without depending on the
> Bareos system.

One could probably extend the tools so all required parameters can be
passed in on the command line.

Nevertheless, you don't need the original SD configuration, you just
need a configuration that is able to read your volumes. This may be as
simple as configuring a single file device and point it at the right
directory or as complicated as setting up a device backed by some object
storage system.

[Andreas Rogge]

Am 24.09.25 um 10:40 schrieb Spadajspadaj:

> And does it matter _what_ plugin the data is from? I mean, could I just
> set up FD with a simple "cat > file" plugin (of course it's a bit of a
> oversimplification but you catch my drift) and restore raw data from
> another plugin?

It doesn't matter which plugin did the backup. Basically, everything
declared with "Plugin =" in your FileSet will not be extracted by bextract.

[Spadajspadaj]

On 9/24/25 10:45, Andreas Rogge wrote:
> Am 24.09.25 um 10:40 schrieb Spadajspadaj:
>> And does it matter _what_ plugin the data is from? I mean, could I
>> just set up FD with a simple "cat > file" plugin (of course it's a
>> bit of a oversimplification but you catch my drift) and restore raw
>> data from another plugin?
> It doesn't matter which plugin did the backup. Basically, everything
> declared with "Plugin =" in your FileSet will not be extracted by
> bextract.

I meant it the other way around. This time completely without bextract.

For example, if I had a backup done with

Plugin = "bpipe:file=/_rpmlist_/rpm.lst:reader=/usr/bin/rpm
-qa:writer=/bin/bash -c 'xargs dnf install -y'"

But tried to extract it to a FD with a job definition of

Plugin = "bpipe:file=/_rpmlist_/rpm.lst:reader=/usr/bin/rpm
-qa:writer=/bin/bash -c 'cat > /tmp/rpm.lst'"

to just get the raw context of the stream (or you could replace cat with
dd or whatever.

Actually, talking about a list of packages done this way I'm not sure if
I wasn't simply able to restore the resulting stream on another FD
_without_ the plugin as just a file.

MK