View Issue Details

IDProjectCategoryView StatusLast Update
0000835bareos-coredirectorpublic2023-09-04 16:36
Reporterdivanikus Assigned Tobruno-at-bareos  
Status closedResolutionno change required 
PlatformLinuxOSDebianOS Version8
Product Version16.2.6 
Summary0000835: Restore job picks wrong storage
DescriptionI'm using version 16.2.6 compiled from source package (

When I'm trying to restore fileset I get the following:

*restore client=zabbix-int-fd select current all done yes
Using Catalog "Metahouse"
Automatically selected FileSet: ZabbixServer
| jobid | level | jobfiles | jobbytes | starttime | volumename |
| 4,949 | F | 557 | 5,332,479,991 | 2017-07-02 01:01:08 | Full-0138 |
| 4,949 | F | 557 | 5,332,479,991 | 2017-07-02 01:01:08 | Full-0140 |
| 5,178 | I | 536 | 5,359,064,324 | 2017-07-03 01:01:15 | Incremental-0139 |
| 5,200 | I | 536 | 5,387,606,276 | 2017-07-04 01:01:13 | Incremental-0007 |
| 5,240 | I | 536 | 5,715,316,484 | 2017-07-17 18:10:47 | Incremental-0012 |
| 5,240 | I | 536 | 5,715,316,484 | 2017-07-17 18:10:47 | Incremental-0014 |
| 5,248 | I | 536 | 5,716,501,252 | 2017-07-18 01:01:00 | Incremental-0012 |
You have selected the following JobIds: 4949,5178,5200,5240,5248

Building directory tree for JobId(s) 4949,5178,5200,5240,5248 ... +++++++++++++++++++++++++++++++++++++++++++++
543 files inserted into the tree and marked for extraction.
Bootstrap records written to /var/lib/bareos/bareos-dir.restore.1.bsr

The job will require the following
   Volume(s) Storage(s) SD Device(s)

    Full-0140 bs-00-full FullFileStorage
    Incremental-0012 bs-00-inc IncFileStorage

Volumes marked with "*" are online.

557 files selected to be restored.

Using Catalog "Metahouse"
Job queued. JobId=5270
You have messages.
18-Jul 02:53 bareos-dir JobId 5269: Start Restore Job RestoreFiles.2017-07-18_02.53.36_33
18-Jul 02:53 bareos-dir JobId 5269: Using Device "FullFileStorage" to read.
18-Jul 02:53 bs-00 JobId 5269: Ready to read from volume "Full-0140" on device "FullFileStorage" (/opt/storage/full/).
18-Jul 02:53 bs-00 JobId 5269: Forward spacing Volume "Full-0140" to file:block 0:2999808192.
18-Jul 02:53 bs-00 JobId 5269: End of Volume at file 0 on device "FullFileStorage" (/opt/storage/full/), Volume "Full-0140"
18-Jul 02:53 bs-00 JobId 5269: Warning: acquire.c:239 Read open device "FullFileStorage" (/opt/storage/full/) Volume "Incremental-0012" failed: ERR=dev.c:661 Could not open: /opt/storage/full/Incremental-0012, ERR=No such file or directory

18-Jul 02:53 bs-00 JobId 5269: Please mount read Volume "Incremental-0012" for:
    Job: RestoreFiles.2017-07-18_02.53.36_33
    Storage: "FullFileStorage" (/opt/storage/full/)
    Pool: Incremental
    Media type: File

It just tries to read Incremental-0012 from wrong storage (FullFileStorage instead of IncFileStorage).
TagsNo tags attached.




2018-01-12 14:22

reporter   ~0002872

Problem is still here, Bareos 17.2 from official repo.

bs-00 JobId 11502: Warning: acquire.c:241 Read open device "FullFileStorage" (/opt/storage/full/) Volume "Incremental-0043" failed: ERR=dev.c:664 Could not open: /opt/storage/full/Incremental-0043, ERR=No such file or directory


2018-06-28 17:14

developer   ~0003056

The Documentation for Media Type points out:

If you are writing to disk Volumes, you must make doubly sure that each Device resource defined in the Storage daemon (and hence in the Director’s conf file) has a unique media type. Otherwise Bareos may assume, these Volumes can be mounted and read by any Storage daemon File device.


It is admittedly not very obvious why this is necesary. However, the documentation contains some more detailed explanations.

We should decide if we really want to consider this a bug, as it can be fixed by configuring different media types.


2020-05-15 06:18

reporter   ~0003988

On the other hand, the documentation for the storage daemon says re device:

If a directory is specified, it is used as file storage. The directory must be existing and be specified as absolute path. Bareos will write to file storage in the specified directory and the filename used will be the Volume name as specified in the Catalog. If you want to write into more than one directory (i.e. to spread the load to different disk drives), you will need to define two Device resources, each containing an Archive Device with a different directory.

I am using file storage, and I have my "tape" files in separate directories. I have performed many restores under this configuration, but today when I tried a restore, I get the type of error reported in this bug.

What are you referring to when you say there are "more detailed explanations" so I can understand how to correct my configuration? Thank you for your response.


2020-05-18 00:58

reporter   ~0003989

Last edited: 2020-05-23 03:21

For the time being -- in particular, to perform an urgent restore at this moment -- I have decided to combine the tape (type Disk, in bareos parlance) directories into one, create one storage daemon Device, and just have all my director Storage's point to the one Storage I defined for the storage daemon.

It works now. I can both backup and restore as before. I still feel that this is either a bug, or maybe there needs to be additional documentation explaining how to use multiple directories in the storage daemon for Disk type Storage's.



2022-08-08 16:32

reporter   ~0004717

Always us a different Media Type if the Device writes/reads from a different directory. Bareos uses the Media Type as an indicator which media types can be put in which device.

If you are using more than one Catalog, some devices get mixed up in the databases, even if they have a different Media Types.


2023-09-04 16:36

manager   ~0005366

Closing old fixed issues

Issue History

Date Modified Username Field Change
2017-07-18 02:34 divanikus New Issue
2018-01-12 14:22 divanikus Note Added: 0002872
2018-01-27 20:02 joergs Status new => acknowledged
2018-01-27 20:02 joergs Product Version 16.2.5 => 16.2.6
2018-06-28 17:14 stephand Note Added: 0003056
2020-05-15 06:18 embareossed Note Added: 0003988
2020-05-18 00:58 embareossed Note Added: 0003989
2020-05-23 03:21 embareossed Note Edited: 0003989
2022-08-08 16:32 sedlmeier Note Added: 0004717
2023-09-04 16:36 bruno-at-bareos Assigned To => bruno-at-bareos
2023-09-04 16:36 bruno-at-bareos Status acknowledged => closed
2023-09-04 16:36 bruno-at-bareos Resolution open => no change required
2023-09-04 16:36 bruno-at-bareos Note Added: 0005366