Hi Bruno,
Am 12.10.2026 um 10:51 schrieb Bruno Bartels (Intero Technologies) via
Bacula-users:
Hi alltogether,
[Bacula-Version: 15.03, from the Docker Images of Bacularis, Bacula-FD
and DIR on a Synology NAS in Docker Container, SD (also in Docker
Container) on external Hetzner VM, there is a "Hetzner Storage Box"
mounted through SMB. Mount parameters:
I assume that everything else works as it should, but...
///$USER.your-storagebox.de/backup on /mnt/backup-ext type cifs
(rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,nolease,username=$USER,uid=115,forceuid,gid=120,forcegid,addr=$IP,file_mode=0660,dir_mode=0770,iocharset=utf8,soft,nounix,serverino,mapposix,reparse=nfs,nativesocket,symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,x-systemd.automount)]/
... the number of options for the mount already indicates that CIFS may
not be a good choice. And while this does not help now -- does Hetzner
only offer CIFS, or are there any other good reasons not to use NFS?
I am fiddeling around with following issue:
We are making one large backup every week with about 2 TB. Writing the
backup runs without issues, but restoring it fails with faults like:
fd-backup0201 JobId 6842: Error: attribs.c:603 File size of restored
file /var/lib/bacula/archive/bacula-restores/$FILENAME not correct.
Original 52429140, restored 31326208.
Have you checked if the original file, while it was backed up, changed
its size?
There is a file set options to have a job message generated in such
cases, which will help a lot in spotting such situations.
The max. Volume Size is set to 10,7 Gb. It seems that restoring fails at
points, where one file has to be restored over two (or multiple
volumes).
This needs verification. So the first thing I propose is
- start a restore through bconsole
- pick only the file that failed restoring
- in the final menu, when you get the yes/mod/no prompt, memorize or
copy the file name of the generated bootstrap file
- in a different shell session, copy that bootstrap file to a place you
can keep it in.
- run the restore
- enable debug tracing of both FD (which generated the message, I
understand) and SD (which you presume has problems reading the file's
data as it spans volumes) using the setdebug command.
'setdebug level=400 trace=1 client=fd-backup0201' would be one
example. Similar for the SD. Trace files will become large.
- let the backup proceed
- in the end, disable tracing
- collect trace files and bootstrap file for analysis. You'll be able to
spot problems but you may need patience. (time stamps may help;
setdebug can also set those: add 'options=t' iirc.)
- If the restore worked all's fine... well, you have proven there's
another problem, but that would be another topic :-)
- if you feel overwhelmed by the trace, try to pick the relevant parts
(but keep all of it!) and bring them, the SD device config and the
bootstrap file here and we'll see if we can get to the bottom of the
matter.
With the bootstrap file, you will have the option to experiment using
bls which will probably require less storage capacity and potentially
save a bit of time, too.
Anyway, and in short: You'll need to collect detailed information as the
problem itself is not something I have seen recently, and it will most
likely be caused on the SD side or even the DIR.
I have also tested restoring with generated files, that are
about 25 GB of size, this works without problems.
So the same scenario, backed up files spanning volumes? That would be an
indication of the problem actually being caused at backup time already.
I have already invested several hours with things like:
* Changing mount parameters to cache=strict|none
* Playing around with SMB-Versions like 2.0, 3.0, e.g.
* Adding "nolease" to mount parameters
* moving the SD to that external host (was former also located on the nas)
Please, has someone some advice for this?
No advice on CIFS except to avoid it :-)
For the Bacula side of things... we'll see wher eit leads.
Cheers,
Arno
Thank you advance!
Bruno
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
