Hi& thanjks for the addition.
So I assume your script works (more or less) similar to the nocache utility.
I figured out there are some edge cases where the nocache does not work
for 100% and the kernel leaves some pages as active.
To prevent this it is recommended to use the "--no-mmap" parameter for
rsync. It might be avery little bit slower but interacts in a better way
with nocache.
Configured my rsync parameters with the --no-mmap now for all hosts
where I use the nocache utility.
Any furhter hints?
/KNEBB
Am 11.08.25 um 10:58 schrieb Andreas Schnederle-Wagner - Futureweb GmbH:
Hi all,
interesting discussion – we’ve observed similar effects with the page cache in
our environment as well, especially when backing up dozens of terabytes of data
across many servers.
It’s not that these effects caused any serious issues on the systems, but in
the statistics it was clearly visible when backups were running and the
existing cache got replaced.
For that reason, we’ve been successfully using the nocache.sh script
(https://raw.githubusercontent.com/virtuozzo/docs_downloads/main/nocache.sh)
from Virtuozzo for several years now on our servers running Virtuozzo 7.5.
With it, the existing cache is no longer evicted during backups, and we have
never experienced any negative impact on the backups themselves – which is
exactly what you would expect from a technical point of view.
Why it works (Virtuozzo specific):
nocache.sh runs the backup process inside its own memory cgroup and applies a
tight page-cache limit (default 256 MB) to that cgroup. This means the backup
can only use a small cache working set, preventing it from pushing out valuable
cached data from the rest of the system.
It does not globally disable caching – metadata (directory entries, inode info)
is not part of the page cache and remains available for fast lookups, which is
particularly helpful for subsequent incremental backups.
The script uses cgroup v1 memory controller features and Virtuozzo-specific
knobs like memory.cache.limit_in_bytes and memory.disable_cleancache, so it
works out of the box on Virtuozzo 7.5.
On systems using pure cgroup v2 (like stock Debian 12), these interfaces aren’t
available by default.
Hopefully these insights are useful to others.
Best regards from Tyrol
Andreas
-----Ursprüngliche Nachricht-----
Von: Christian Völker via BackupPC-users <[email protected]>
Gesendet: Samstag, 9. August 2025 21:18
An: [email protected]
Cc: Christian Völker <[email protected]>
Betreff: Re: [BackupPC-users] Cache Poisoning- solution?
Hi,
this was the type of discussion I wanted to have. Thanks!
I did not think about the metadata and the other shares, indeed. So according
to your comments I took a deeper dive to nocache:
It marks the pages used by the kernel for reading the data as „do not need“. So
after reading a chunk the kernel frees the memory immediately.
So for the next chunk it will be re-used. So the existing page cache does not
get polluted by backup.
But metadata and directory entries will still be cached- as they are not in
page cache anyways they are not affected. So I guess for subsequent incremental
backups this will be perfect.
Looks like my initial thoughts were fine and because of metadata still caching
it is really a very good option to improve setup.
However, for running databases this is indeed not suitable- just as no backups
are…
Grüsse
Christian Völker
Am 09.08.2025 um 17:00 schrieb G.W. Haywood <[email protected]>:
Hi there,
On Sat, 9 Aug 2025, Christian V?lker wrote:
I noticed ... high CPU usage 20% ... throwing away "old" filesystem
cache blocks to cache ... directory ... 400GB ... blocks are read only once ...
thrown away a couple of hours later ...
...
... "RsyncClientPath" ... to "/usr/bin/nocache /usr/bin/rsync".
Now the blocks read during backup are not going into the cache ...
So what do you think? Is this a good solution? Or are there any pitfalls?
Does using 20% CPU for a couple of hours actually matter?
Presumably by doing this you'll be defeating _all_ caching of anything
you're backing up, not just caching of the 400GB directory. That will
include directory contents as well as file contents, and may possibly
be particularly relevant to incremental backups. You're obviously
well in tune with your systems so I guess you'll probably notice any
untoward effects. I'd expect significantly increased disc activity
because of directory reads which are no longer cached. That might be
more relevant for the life expectancy of spinning rust than for SSDs.
It might mean that the backups take significantly longer. I'm sure
we'll all be interested in your reports, if you find such effects.
In a case like this as the data you're backing up is relatively static
I think I'd be tempted to put the 400GB directory in a share all of
its own, and back it up on a different schedule. But the 'nocache'
utility was created expressly for your use case so I don't think it's
likely that there will be any serious downsides unless there's some
terrible flaw in the implementation which I guess can't be ruled out.
I'd be reluctant to do this to my backups for that reason.
FWIW where I have for example large database directories - of course
not necessarily static data - I don't let BackupPC anywhere near them.
Instead I use the DB facilities to create data dumps at intervals (via
cron), and then back up the data dumps using rsync (again via cron).
--
73,
Ged.
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
