Hello all,
Sorry for this late reply. (According to Murphy's law, our Bacula server
failed, and it took some time to figure out that the SAS card was dead, and
get another one ...)
I did some tests, and there's something new :
In fact, the fileset seems to be OK, and the Incremental "could" resume...
If I do an estimate without accurate, I get around 18K files / 3To , which
looks like "OK" for incremental :
*estimate accurate=no level=incremental job=BackupARCHIVES
Using Catalog "MyCatalog"
Connecting to Client lto8-fd at localhost:9102
2000 OK estimate files=17,949 bytes=3,465,825,854,672
But with accurate=yes , I get 530K files / 23To, which is (almost ? see
below) a FULL backup :
*estimate accurate=yes level=incremental job=BackupARCHIVES
Using Catalog "MyCatalog"
Connecting to Client lto8-fd at localhost:9102
2000 OK estimate files=530,779 bytes=23,005,947,679,372
So I have tried to estimate my job with acurate=true and several options
for accurate in the fileset :
FileSet {
Name = "ARCHIVES"
Ignore FileSet Changes=yes
Include {
Options {
signature=MD5
*#I have tried many accurate options here : mcso5, mso5,
so5,M,m,o5,sm,s, or nothing (line commented)*
accurate=s
mtimeonly=yes
#Verify = pin5
}
File = /path/to/ARCHIVES
}
Exclude {
File = "/path/to/ARCHIVES/#recycle"
}
}
But all my attempts with Job accurate=yes give me almost the same result -
but slightly different sometimes ( could be 531,057 files, or 530,719
or 530,779 files, depending on the accurate option chosen...)
As I understand it, accurate=s in the Fileset definition should tell Bacula
that a file with "same path, same size" shouldn't be backed up again...
But this isn't the case and my understanding is clearly wrong...
And as I understand it also, accurate=no would lead, in case of restore, to
restore even suppressed and moved files, which is not what I want.
So I am stuck : resume incremental backup without accurate option, or
restart a full backup with accurate option. Or understand better things ...
:)
Can anyone help me there ?
Thanks a lot !
Sam
Le mar. 12 nov. 2024 à 17:18, Radosław Korzeniewski <
rados...@korzeniewski.net> a écrit :
> Hello,
>
> wt., 12 lis 2024 o 12:00 Samuel Zaslavsky <s...@w4tch.tv> napisał(a):
>
>> So, precisely, how does Bacula "decides" a fileset is different from
>> another one ?
>>
>
> Bacula is checking the fileset changes based on a fileset content.
>
>
>> Where is this information stored in the database ?
>>
>
> It is a fileset table.
>
>
>> How could I trick bacula to believe that all previous jobs have been made
>> with the new fileset : This would be OK for me !
>> My idea was that it would be using the fileset.md5 field (or createtime ?)
>>
>
> From what I know Bacula is checking the md5 column for this purpose. So,
> if your new fileset md5 will be the same of which is already saved then
> Bacula won't have any traces it is a different fileset.
>
>
>>
>> So, a few related questions : When will bacula add another entry in the
>> fileset database table ?
>>
>
> If your current configuration includes a selected fileset and md5 does not
> match the one saved in the database then Bacula will create a new entry.
>
>
>> It seems it's not when doing an estimate...
>> So, should I start ( and abort quickly) a dummy job using the "new"
>> fileset, to see the "new" fileset in the database ? And then try to trick
>> Bacula into thinking the old one is the new one ?
>>
>
> Yes, it sounds good to me.
>
>
>> If this is a pertinent approach, how exactly do that ?
>> For example, where in the database is the information that a "file"
>> belongs to some files set ?
>>
>
> Database relation.
> bacula=# \d file
> Table "public.file"
> Column | Type | Collation | Nullable | Default
>
>
> -----------+----------+-----------+----------+--------------------------------------
> fileid | bigint | | not null |
> nextval('file_fileid_seq'::regclass)
> jobid | integer | | not null |
> ...
> bacula=# \d job
> Table "public.job"
> Column | Type | Collation | Nullable |
> Default
>
> -------------------+-----------------------------+-----------+----------+------------------------------------
> jobid | integer | | not null |
> nextval('job_jobid_seq'::regclass)
> filesetid | integer | | | 0
> ...
> bacula=# \d fileset
> Table "public.fileset"
> Column | Type | Collation | Nullable |
> Default
>
> ------------+-----------------------------+-----------+----------+--------------------------------------------
> filesetid | integer | | not null |
> nextval('fileset_filesetid_seq'::regclass)
>
> Is it in the file.lstat column ? If yes, how is it "encoded" here ?
>>
>
> This column is a "direct" serialisation of lstat(2), struct stat {};
> buffer. It is (to some extent) OS dependent.
>
>
>>
>> Basically, I need to understand how the relationship between fileset conf
>> <--> fileset in database <--> files in fileset is handled...
>>
>>
> When Bacula detects a fileset change, because the md5 is different then
> the one saved in the database then it creates a new entry. Then a job will
> get a new filesetid as a reference for job entry in the database and all
> files saved will get a jobid reference.
>
>
>> Or maybe I am completely wrong here ?
>>
>
> You are just asking questions. You can't be wrong asking questions.
>
>
>> The filesystem to be backed up is mounted as NFS share on the bacula host.
>>
>
> Any chance you can access this filesystem directly without mounting it on
> the remote host? It would be better.
>
>
>> Is it possible that the reboot/remount changed a key parameter for Bacula
>> ?
>>
>
> Well. Let's assume your first mount point is: /mnt/data. Then you reboot
> and the new mount point is /mnt/data1. Then it makes a huge difference for
> Bacula, for sure.
>
>
>> So that Bacula recognizes well the filesystem as the old one,
>>
>
> It doesn't matter. What matters are some metadata for the file, i.e.
> modify time. You can configure what metadata should be verified in this
> case. But you can't force Bacula to not backup a file which does not exist
> at the previous backup jobs.
>
>
>> but doesn't recognize any file anymore ? ( Remember that fileset name,
>> and all paths in the fileset configuration are the same as before ! )
>>
>
> I'm pretty sure your fileset content is different then the one used
> before, so Bacula wants to create a full backup.
>
> best regards
> --
> Radosław Korzeniewski
> rados...@korzeniewski.net
>
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
