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/
