Restore of windows client does not show any file to restore

138 views
Skip to first unread message

Ricardo Rio

unread,
Mar 7, 2024, 9:13:47 AM3/7/24
to bacularis
Hi,

I'm pretty new to Bacula and Bacularis, and I'm running Bacula 13.0.4 and Bacularis 2.6.0 on Ubuntu 22.04.

When I do a backup on the linux File Daemon I'm able to see all the files on the backup and I'm able to recover them 1 by 1, but when I try to do the same thing on a Windows File Daemon when I try to restore the job I can't see any file on the backup, I have double check and the retention period is ok, and dont see anypurge happening, on my job I can see my files there but when I try to restore I can't see any file. I tried this a couple of weeks ago in another test system with debain server and windows client and I was able to see the files, so at this point I'm pretty lost if it is something with Bacula, Bacularis or if I'm missing some configuration.

Is anyone able to help on this?


Best Regards,
Ricardo Rio 
2024-03-07 14_09_30-Bacularis - Bacula Web Interface.png
2024-03-07 14_10_39-Bacularis - Bacula Web Interface.png

Marcin Haba

unread,
Mar 7, 2024, 9:32:53 AM3/7/24
to Ricardo Rio, bacularis
Hello Ricardo,

Welcome to the Bacularis user group. Thanks for sending your question here.

This situation looks like there is no Full backup for a given job
finished successfully for the job that you are trying to restore.

For start I would propose to check it manually in the bconsole 'list
jobs' command or do a test with '.bvfs_get_jobids' bconsole command.
This command displays all single jobids that are taken into account
for restoring for given jobid:

.bvfs_get_jobids jobid=XXXXX

For example, if you put there incremental jobid 36953, it displays all
jobs until latest full that are required to build restore directory
tree to select and to do consistent backup restore:

.bvfs_get_jobids jobid=36953
36815,36851,36885,36900,36953

If this command for your jobid does not return anything, it means that
there is no Full backup finished successfully.

Please let us know if it is this case. Thanks.

Best regards,
Marcin Haba (gani)
> --
> You received this message because you are subscribed to the Google Groups "bacularis" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bacularis+...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/bacularis/123b1424-ea25-4e48-855a-870fdcb647acn%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
"Greater love hath no man than this, that a man lay down his life for
his friends." Jesus Christ

"Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie
za przyjaciół swoich." Jezus Chrystus

Ricardo Rio

unread,
Mar 7, 2024, 10:25:35 AM3/7/24
to Marcin Haba, bacularis
Hi Marcin,

Thanks for the quick reply!

So I have run the commands you have sent on the bconsole and I believe that the backup finished with success, I have added a screenshot of the commands sent. Are you able to check if it is ok?

Thanks again,
Best regards,
Ricardo Rio.
2024-03-07 15_17_30-Bacularis.png

Marcin Haba

unread,
Mar 7, 2024, 11:30:53 AM3/7/24
to Ricardo Rio, bacularis
Hi Ricardo,

Thanks for this test. Yes, it looks that you have a full backup. This
part is correct.

I would propose to do one more test, to see if the Bacula Bvfs cache,
that is used for this restore is built correctly. Without this cache
it will be not possible to browse files, like in this case. To see
what is in cache, please run this bconsole command (yes, 'path='
parameter needs to be empty):

.bvfs_lsdirs jobid=15 path=

and we will see if it returns any Windows drive letter from Bvfs cache.


Here you can see how I navigate in this cache for my jobid 38242:

*.bvfs_lsdirs jobid=38242 path=
84773 0 0 0 A A A A A A A A A A A A A A .
87556 0 0 0 A A A A A A A A A A A A A A M:/

*.bvfs_lsdirs jobid=38242 path=M:/
87556 0 0 0 A A A A A A A A A A A A A A .
84773 0 0 0 A A A A A A A A A A A A A A ..
87555 0 0 0 A A A A A A A A A A A A A A PRACA/

*.bvfs_lsdirs jobid=38242 path=M:/PRACA/
87555 0 0 0 A A A A A A A A A A A A A A .
87556 0 0 0 A A A A A A A A A A A A A A ..
87542 0 17604382 38242 A A EH/ B A A A A A A Bl6c1m Blp6Hg Blp6Hg A A
L Q ZADANIE123/

If you will not have anything in cache, then we should check building
the cache command. It is this bconsole command:

.bvfs_update jobid=15

and after could you check once again this list command?

.bvfs_lsdirs jobid=15 path=

Thanks for your test.

Best regards,
Marcin Haba (gani)

Ricardo Rio

unread,
Mar 7, 2024, 12:07:12 PM3/7/24
to Marcin Haba, bacularis
Hi Marcin,

Again thanks for the help.

I have run the commands you have sent and I can see that I do not have the path which is weird, also when submitting your command to update the cache, it seems that it did not work, you can have a look to the image output.

Best regards,
Ricardo Rio.
2024-03-07 17_04_00-Window-bacularis.png

Marcin Haba

unread,
Mar 7, 2024, 12:28:15 PM3/7/24
to Ricardo Rio, bacularis
Hi Ricardo,

Yes, it is the reason.

I would propose to do two things:

1) Clear all existing Bvfs cache by bcommand below and do re-test with
the restore:

.bvfs_clear_cache yes

2) If the 1) will not help, then you can check if Bacula Catalog
database user (usually 'bacula' user) is capable to write to these two
Bacula SQL tables:

- pathvisibility
- pathhierarchy

Best regards,
Marcin Haba (gani)

Ricardo Rio

unread,
Mar 7, 2024, 12:47:42 PM3/7/24
to Marcin Haba, bacularis
Hi Marcin,

I did as requested but still no luck.

Did not check the DB yet, but if the user did not had access, I should not be able to access the path on the linux server File Daemon? 

Best regards,
Ricardo Rio.


2024-03-07 17_42_15-Bacularis - Bacula Web Interface-LinuxDaemon-Restore.png

Marcin Haba

unread,
Mar 8, 2024, 2:51:09 AM3/8/24
to Ricardo Rio, bacularis
Hi Ricardo,

Yes, it is true about db access and Linux and Windows files. In any
case, I think it is always good to make sure about the db permissions
because they could changed after building cache for jobs done on
linux.

I did test on my side with Windows Bacula client 13.0.4 and here the
directory tree is built correctly.

Another thing to check could be enabling debug for Bacula Director and
observing in the debug file why the cache is not written. To enable
debug you can use this bconsole command:

setdebug level=500 tags=sql,bvfs trace=1 dir

On the Director host in Bacula working directory you will find a file
yourdirector-dir.trace. Inside this file you will find debug.

Best regards,
Marcin Haba (gani)

Ricardo Rio

unread,
Mar 8, 2024, 5:31:51 AM3/8/24
to Marcin Haba, bacularis
Hi Marcin,

Thanks again, I have enabled the log as instructed, and I have made another restore (file in attachment: "RestoreLog.txt"), but still with the same issue.
Then I have made another backup on the same client on a different folder with "dummy" files and gather the log in attachment: "Archive.txt" with JobID=18
After I did a restore of this archive (JobID=18) and still got the same error, but I also got the log in attachment: "RestoreLog2.txt". I don't know if with these logs you are able to pinpoint what is the issue.
From what I could see it seems that is adding the files to the database, when connecting to the DB the files and folders are present (please check images in attachment).
Really don't know what is wrong..

Best regards,
Ricardo Rio.
RestoreLog2.txt
Archive.txt
Table Pathvisibility.png
Table Pathhierarchy.png
Table Path.png
RestoreLog.txt
Table file.png

Marcin Haba

unread,
Mar 8, 2024, 5:39:33 AM3/8/24
to Ricardo Rio, bacularis
Hi Ricardo,

Many thanks for providing all the details. Yes, indeed, it gives more
light on this problem.

In Bacula in all Linux and Windows paths we use slashes. In your lists
I see for Windows paths are used backslashes.

There is:

C:\test

There should be:

C:/test

Thanks in advance for trying once again with the changed paths.

Good luck.

Best regards,
Marcin Haba (gani)

Ricardo Rio

unread,
Mar 8, 2024, 6:10:52 AM3/8/24
to Marcin Haba, bacularis
Hi Marcin,

You are the best!! Thanks it was indeed the slash... I must have edited the fileset and put the wrong slash... That's why it was working on Linux!!

One last question, do you know what is the command to put the logging back to normal?

Best regards,
Ricardo Rio.

Marcin Haba

unread,
Mar 8, 2024, 6:27:19 AM3/8/24
to Ricardo Rio, bacularis
Hi Ricardo,

Great to hear that it started working :-) Thanks for letting us know.

For the debugging, you can disable it by this bconsole command:

setdebug level=0 dir

or alternatively you can restart the director which will disable the
director debug too.

Best regards,
Marcin Haba (gani)

Ricardo Rio

unread,
Mar 8, 2024, 7:12:43 AM3/8/24
to Marcin Haba, bacularis
Hi Marcin,

Perfect thanks!!!

Case solved :)

Best regards,
Ricardo Rio.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages