>>>>> On Mon, 22 Jan 2024 11:11:44 +0100, Marco Gaiarin said:
>
> I'm using Bacula to put on tapes (LTO9) a backup collected from different
> sources via 'rsnapshot'; if now known, rsnapshot is a perl wrapper script
> around rsync that leveraging the UNIX filesystem capability (eg, hard link)
> permit to have 'snapshots' of filesystems.
>
> Practically, some rsync invocation sync some source servers to a destination
> folder ('.sync'); after the sync, folders with a prefedined retention get
> rotated:
>
> [2024-01-21T15:05:23] /usr/bin/rsnapshot daily: started
> [2024-01-21T15:05:23] Setting locale to POSIX "C"
> [2024-01-21T15:05:23] echo 32628 > /var/run/rsnapshot.pid
> [2024-01-21T15:05:23] /usr/bin/rm -rf /rpool-backup/rsnapshot/daily.6/
> [2024-01-21T15:25:28] mv /rpool-backup/rsnapshot/daily.5/
> /rpool-backup/rsnapshot/daily.6/
> [2024-01-21T15:25:28] mv /rpool-backup/rsnapshot/daily.4/
> /rpool-backup/rsnapshot/daily.5/
> [2024-01-21T15:25:28] mv /rpool-backup/rsnapshot/daily.3/
> /rpool-backup/rsnapshot/daily.4/
> [2024-01-21T15:25:28] mv /rpool-backup/rsnapshot/daily.2/
> /rpool-backup/rsnapshot/daily.3/
> [2024-01-21T15:25:28] mv /rpool-backup/rsnapshot/daily.1/
> /rpool-backup/rsnapshot/daily.2/
> [2024-01-21T15:25:28] mv /rpool-backup/rsnapshot/daily.0/
> /rpool-backup/rsnapshot/daily.1/
> [2024-01-21T15:25:28] /usr/bin/cp -al /rpool-backup/rsnapshot/.sync
> /rpool-backup/rsnapshot/daily.0
> [2024-01-21T16:14:44] rm -f /var/run/rsnapshot.pid
> [2024-01-21T16:14:44] /usr/bin/logger -p user.info -t rsnapshot[32628]
> /usr/bin/rsnapshot daily: completed successfully
> [2024-01-21T16:14:44] /usr/bin/rsnapshot daily: completed successfully
>
> as you can see, last (daily) backup get rotated, all backup get moved, and
> the '.sync' folder get copied (with hard link) to 'daily.0'.
>
> So seems to me there's no massime modification of '.sync' dir.
>
>
> But if i do a full on '.sync', and subsequent an incremental, i get and
> incremental with roughly the same files of full:
>
> 20-Jan 00:49 ibrpve3-sd JobId 16078: Elapsed time=04:48:47, Transfer
> rate=84.64 M Bytes/second
> 20-Jan 00:50 ibrpve3-sd JobId 16078: Sending spooled attrs to the Director.
> Despooling 731,524,889 bytes ...
> 20-Jan 01:01 lnfbacula-dir JobId 16078: Bacula lnfbacula-dir 9.4.2 (04Feb19):
> Build OS: x86_64-pc-linux-gnu debian 10.5
> JobId: 16078
> Job: PUG-IBR-IBRPVE3.2024-01-19_20.00.00_37
> Backup Level: Full
> Client: "pug-ibr-ibrpve3-fd" 9.4.2 (04Feb19)
> x86_64-pc-linux-gnu,debian,10.5
> FileSet: "PVETerzoNodoStd" 2023-12-28 23:00:00
> Pool: "PUG-IBR-IBRPVE3LTOPool" (From Job resource)
> Catalog: "BaculaLNF" (From Client resource)
> Storage: "IBRPVE3LTO" (From Job resource)
> Scheduled time: 19-Jan-2024 20:00:00
> Start time: 19-Jan-2024 20:00:03
> End time: 20-Jan-2024 01:01:53
> Elapsed time: 5 hours 1 min 50 secs
> Priority: 10
> FD Files Written: 2,145,479
> SD Files Written: 2,145,479
> FD Bytes Written: 1,466,069,549,214 (1.466 TB)
> SD Bytes Written: 1,466,566,045,401 (1.466 TB)
> Rate: 80953.6 KB/s
> Software Compression: None
> Comm Line Compression: None
> Snapshot/VSS: no
> Encryption: no
> Accurate: no
> Volume name(s): IBRPVE3_0004
> Volume Session Id: 31
> Volume Session Time: 1702656598
> Last Volume Bytes: 1,467,000,503,296 (1.467 TB)
> Non-fatal FD errors: 0
> SD Errors: 0
> FD termination status: OK
> SD termination status: OK
> Termination: Backup OK
>
> 22-Jan 03:45 ibrpve3-sd JobId 16148: Elapsed time=04:43:55, Transfer
> rate=86.07 M Bytes/second
> 22-Jan 03:46 ibrpve3-sd JobId 16148: Sending spooled attrs to the Director.
> Despooling 672,414,561 bytes ...
> 22-Jan 03:56 lnfbacula-dir JobId 16148: Bacula lnfbacula-dir 9.4.2 (04Feb19):
> Build OS: x86_64-pc-linux-gnu debian 10.5
> JobId: 16148
> Job: PUG-IBR-IBRPVE3.2024-01-21_23.00.00_49
> Backup Level: Incremental, since=2024-01-20 23:00:03
> Client: "pug-ibr-ibrpve3-fd" 9.4.2 (04Feb19)
> x86_64-pc-linux-gnu,debian,10.5
> FileSet: "PVETerzoNodoStd" 2023-12-28 23:00:00
> Pool: "PUG-IBR-IBRPVE3LTOPool" (From Job resource)
> Catalog: "BaculaLNF" (From Client resource)
> Storage: "IBRPVE3LTO" (From Job resource)
> Scheduled time: 21-Jan-2024 23:00:00
> Start time: 21-Jan-2024 23:00:03
> End time: 22-Jan-2024 03:56:43
> Elapsed time: 4 hours 56 mins 40 secs
> Priority: 10
> FD Files Written: 1,919,122
> SD Files Written: 1,919,122
> FD Bytes Written: 1,465,811,057,734 (1.465 TB)
> SD Bytes Written: 1,466,261,528,393 (1.466 TB)
> Rate: 82348.9 KB/s
> Software Compression: None
> Comm Line Compression: None
> Snapshot/VSS: no
> Encryption: no
> Accurate: no
> Volume name(s): IBRPVE3_0004
> Volume Session Id: 33
> Volume Session Time: 1702656598
> Last Volume Bytes: 4,440,424,676,352 (4.440 TB)
> Non-fatal FD errors: 0
> SD Errors: 0
> FD termination status: OK
> SD termination status: OK
> Termination: Backup OK
>
> so seems that bacula think that all file synced by rsync get modified, and
> reinsert into the backup.
>
>
> Clearly i've tried to search for 'bacula incremental rsyc' but found
> nothing.
>
>
> Someone have some clue? Thanks.
I suspect the problem is with rsnapshot, not rsync, in particular this
command:
> [2024-01-21T15:25:28] /usr/bin/cp -al /rpool-backup/rsnapshot/.sync
> /rpool-backup/rsnapshot/daily.0
This will change the hard link count of every file in .sync and hence also
change its ctime. Bacula copies a file if its ctime has changed by default.
You could make Bacula ignore the ctime by setting the "Accurate = yes" option
in the Job definition and then set the "accurate" option in the fileset to
some combination of option letters that detects most changes without including
the ctime (see the docs).
__Martin
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
