Re: fileset and moving source backup directory

Hi Lionel,

Am 05.11.2024 um 11:31 schrieb Lionel PLASSE:
> Hello,
> 
> I recently move a full directory form D: to G:
> 
> I change my FileSet Accordingly with IgnoreFilesetChanges option.
> 
> But, the next Incremental backup  will fully backup the directory as it is a
> new Path.

That's expected behaviour -- after setting Ignore Fileset Changes, the 
next backup using the fileset should be upgraded, and *from then on* 
you're on your own.

If it turns out this is not helpful -- as it seems to be the case -- you 
can tweak the catalog database to have the last (sequnce of) backups 
that are relevant make it appear they already used the new fileset.

This has a certain risk, and I suggest to carefully verify the process 
and results.

In principle, Bacula keeps track of the changed file sets by storing a 
hash of their relevant contents:

Enter SQL querfileset where fileset='TypicalServer';
+-----------+---------------+------------------------+---------------------+---------+
| filesetid | fileset       | md5                    | createtime 
   | content |
+-----------+---------------+------------------------+---------------------+---------+
|         4 | TypicalServer | s9/JT6+6m3lbw95ub9+S4B | 2019-08-21 
12:40:32 |         |
|         5 | TypicalServer | t4/jQ9UUIG+KW++Af+NinC | 2019-08-21 
12:48:31 |         |
|         6 | TypicalServer | Zm/Nd/lpVk+ee++ddQ/H2B | 2019-08-21 
12:50:45 | files   |
+-----------+---------------+------------------------+---------------------+---------+

he dates are interesting as they allow you to actually see what's going 
on. The md5 column is the hast. The filesetid is what is referenced with 
a job:

select jobid,job,realendtime,jobfiles,filesetid from job where 
filesetid=6 and jobfiles>0 limit 1;
+--------+-----------------------------------+---------------------+----------+-----------+
| jobid  | job                               | realendtime         | 
jobfiles | filesetid |
+--------+-----------------------------------+---------------------+----------+-----------+
| 47,868 | radius-all.2024-10-03_23.05.04_13 | 2024-10-03 23:07:31 | 
   80 |         6 |
+--------+-----------------------------------+---------------------+----------+-----------+

What you can do is prepare the list of jobs to tweak (lastest full and 
all subsequent ones for the relevant job to avoid misunderstandings with 
reference jobs), find check they all use the expected file set, that is 
the one with the filesetid referencing your old fileset, and then update 
them all to use the new filesetid.

You should document that.

A SQL command such as 'update job set filesetid=9876543 comment='Updated 
file set from old 2021-09-02 to new 2024-11-05 one manually, blame me if 
anything goes wrong!' where jobid in (1,2,3,4,whatever-the-list-is);
would work.

Create a catalog backup first, and make sure no jobs run at the time of 
your modification.

Test this very carefully in a zest instance and with a non-important 
test job in your production system. Then, double-check all identifiers 
before actually doing the change.

Did I mention you should very carefully test each step?

> Is there a way to avoid this and to "tell" the director that it is the same
> directory.

An alternative that might be interesting could be path changes in the 
catalog or a very particular setup of base jobs and strip prefixes, but 
I would'nt want to go into that direction... they would be more trouble 
than a new full backup, even if available bandwidth to size ratio is 
very bad :-)

Good luck, and don't forget careful testing!

Cheers,

Arno


> Cause as the SD is outside the LAN and have a very poor bandwidth so the
> backup rate is really slow . I don't want to save the full 800GB for a few
> different bytes.
> I thought of renaming  all the corresponding path record in the database but
> it's quite dangerous.
> 
> Any possibility with bconsole has been provided?
> 
> thanks
> 
> 
> 
> _______________________________________________
> 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