Re: fileset and moving source backup directory

Hi Lionel,

Am 05.11.2024 um 22:09 schrieb Lionel PLASSE:
> 
> Great, but I won't ^^ .
> 
> It could be cool but too many manipulations, too dangerous.

Actually, the File Set id update is pretty safe :-)

But your decision is quite ok, it's always balancing risk against other 
factors, and once you start taking backups seriously, the focus does 
shift a bit...

> If  I can  do something with bconsole like updating a Path by console it could be a great fonction cause if I restore an old backup and don't remember the directory had already moved I could keep prefix and restore to d: instead of g: . So I can't do a full restore with replace and relocate.   If devs see what I say I think it could be a cool function to add to bconsole or as a tool in dbcheck or similar tool .

I'm not sure you will be able to convince the developers, but of course 
feel free to submit that as a feature request. The effort implementing 
this will be considerable, and the new functionality quite peculiar, so 
you'd need to make a very good case of it... and in the end, the paths 
are also stored in the volume, and thus we would have situations where 
catalog and volume represent different realities, and that would need 
thinking about how to handle restores, copies, migration, bscans (which 
IMO you should mostly not do anyway, but that's a diferent topic...) and 
verify jobs. I suspect there would be features that can be helpful and 
would be easier implemented.

How about job comments that get forcibly displayed when you start a 
restore including that jobs data? You could then just set one of those 
after twaeking a catalog entry, and would at least reduce the risk of 
forgetting about such a change.

If you submit that feature request, I'd upvote it ;-)
(But keep in mind there are no votes anyway...)

Cheers,

Arno

> Thanks for the time you spent answering.
> 
> 
> 
> 
> -----Message d'origine-----
> De : Arno Lehmann via Bacula-users <[email protected]>
> Envoyé : mardi 5 novembre 2024 12:45
> À : [email protected]
> Objet : Re: [Bacula-users] 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

-- 
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück


_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users