bug? bareos reuses volume files not in catalog

[Chad W Seys]

Hello all,
I've noticed that bareos will reuse volume files which aren't in the
database.
This is a big problem in the following situation: You lose the
catalog. (Say your building burns down, but you have fortunately saved
the volume files offsite.) So you begin bscanning volume information
back into the catalog. At the same time you begin making backups as
computers come back online. While backing up these computers, bareos
might choose a volume name which matches one fo the existing file names.
If it does, it adds the volume name to the catalog, then reuses the
volume file, overwriting the volumes' information which has not yet been
bscanned into the catalog. Oops, that data is no longer recoverable!
The obvious thing would be to not allow bareos to reuse volumes which
are not already in the catalog.

Thanks!
Chad.

[Vitaly Solntsev]

Hi, Chad

>   I've noticed that bareos will reuse volume files which aren't in the
>database.

afaik, bareos cannot re-use volumes which not in catalog database because it simply doesn't know about their existence.

To use volume, bareos looks in the catalog database for the volumes for writing (f.e. in "Append" status) or which can be re-used ("Recycle"). 

If bareos cannot find in the catalog db volumes for writing, it will generate a new volume name based on Label Format definition in the pool.

Do you mean that the new volume name from pool definition produces the same name as old (but not bscanned yet) volume named?

You may easily avoid this behavior with ${JobId} or start time in Label Format.

Or was re-used currently bscanning volume?

>   This is a big problem in the following situation:  You lose the
>catalog. (Say your building burns down, but you have fortunately saved
>the volume files offsite.) So you begin bscanning volume information
>back into the catalog.  At the same time you begin making backups as
>computers come back online.  While backing up these computers, bareos
>might choose a volume name which matches one fo the existing file names.
>  If it does, it adds the volume name to the catalog, then reuses the
>volume file, overwriting the volumes' information which has not yet been
>bscanned into the catalog.  Oops, that data is no longer recoverable!

we should avoid incremental backups until bscan completed, otherwise, the incremental backup can be based on improper Full or contain already backed up (but not scanned yet) files.

Also, keep in mind, that bscanned to the catalog db volumes have 'Archive' status which prevents them from re-using (we have to change the status for correct volume rotation)

--
You received this message because you are subscribed to the Google Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/83e5ac9e-3aa7-4fce-38e7-7339ddfa5c58%40physics.wisc.edu.

[Chad W Seys]

Hi Vitaly,

> Do you mean that the new volume name from pool definition produces the
> same name as old (but not bscanned yet) volume named?

Exactly! And then the volume file is reused, data destroyed.

> You may easily avoid this behavior with ${JobId} or start time in Label
> Format.

I think it would be better to modify bareos to choose a volume name (for
the db) which does not match an existing volume file.
In an emergency people don't want to discover (too late) that they
need to do special tricks. For example,
https://docs.bareos.org/Appendix/DisasterRecoveryUsingBareos.html does
not mention changing one's label format. (Nor does it mention
pre-labeling volumes whose db name does not collide with existing file
volume names, the trick I discovered.) Nor should it, Instead, change
bareos to be smarter and safer.

> Or was re-used currently bscanning volume?

I haven't noticed this.

> we should avoid incremental backups until bscan completed, otherwise,
> the incremental backup can be based on improper Full or contain already
> backed up (but not scanned yet) files.

It is good to keep in mind. However, in the scenario where the building
burns down the clients are mainly a) ones that haven't been restored and
aren't backing up b) ones that have been restored from a bscan and are
once again backing up and c) new clients which have never been backed
up. Unfortunately the b) and c) clients can overwrite the a) clients data.

> Also, keep in mind, that bscanned to the catalog db volumes have
> 'Archive' status which prevents them from re-using (we have to change
> the status for correct volume rotation)

A wise precaution. I propose volume files which aren't in bareos db be
treated in the same way. :)

Have a good one!
Chad.