[Borgbackup] Backup taking very long - sometimes

[borg-samuel at balkonien.org]

Thank you!
I guess I'm getting closer. There is a chown -R which runs over the
whole filesystem there.

It was part of hardened file permissions for nextcloud, but now I see
they are not recommended anymore. So I will retire this script and hope
the backup will be faster in the future.

Thank you!
Samuel

Am 17.09.20 um 13:07 schrieb Thomas Waldmann:
>> With the option "--list --filter="AME"" I see that some backups run very
>> fast and only a considerable amount of files is changed or added.
>> The backups that have a really long duration backup a whole lot of files
>> as modified which should be untouched.
>>
>> The source is a nextcloud data directory and the data is on a btrfs volume.
> Is it always mounted to same mountpoint (same base path)?
>
> Checks the docs about the files-cache, it uses full path, ctime, inode
> number and file size (defaults) to determine whether a file is still the
> same.
>
> In that case, processing is very fast, because file content does not
> need to be read.
>
> In the other case, if content might have changed, all content is read,
> chunked, hashed, deduplicated, new chunks compressed, encrypted,
> authenticated, transferred to repo. This is significantly slower.
>
>
> full path -> always use same mountpoint / have stable full pathes
>
> ctime -> avoid stuff like frequent chown -R / chmod -R (because they
> trigger ctime change)
>
> inode -> have stable inode numbers (frequently an issue with network
> filesystems, some have options for stable inode numbers and also you can
> use --files-cache=ctime,size to not check for inode number change)
>
> size -> usually not a problem. if size changes, file contents have
> changed for sure.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/borgbackup/attachments/20200917/8cc05f3c/attachment-0001.html>