Standalone backup agents for Linux, Mac, AIX & Solaris workloads on-premises or in the public cloud
Post Reply
aj_potc
Enthusiast
Posts: 99
Liked: 19 times
Joined: Mar 17, 2018 12:43 pm
Contact:

Linux incremental volume backups larger than expected

Post by aj_potc »

Case #05485189

Veeam support refuses to look into this case due to my OS version (Rocky Linux 8.6), which they say is unsupported. I don't understand this refusal, as the support issue I'm raising has not been affected by changes in the OS, and the OS I'm using is simply a rebuild of RHEL 8.6, which is the latest available.

In any case, my issue is that daily incremental backups appear larger than I would expect (and always have for the system in question). Is there any method in which I can determine the reason for their size? I realize this may be difficult since Veeam uses CBT to do the backup, but I'd really like to get to the bottom of it and hopefully save some space on my backup repositories.

Thank you very much for any suggestions.

Secondly, is it official Veeam support policy to deny any support for clones of RHEL such as Rocky and Alma? Or am I denied support because I'm using version 8.6, which is not yet on your list of supported versions of RHEL? Some clarification here would be helpful, as I don't see the point in paying for support if Veeam will refuse to cover the most popular CentOS 8 replacements.

Thank you.

Mildur
Veeam Software
Posts: 3164
Liked: 1083 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: St. Gallen, Switzerland
Contact:

Re: Linux incremental volume backups larger than expected

Post by Mildur »

Hi AJ
Is there any method in which I can determine the reason for their size?
There isn't a direct method built-in in our products. We scan the changed data which CBT is telling us to scan.
Our support would start with the debug logs. They are stored at this location: /var/log/veeam/
Secondly, is it official Veeam support policy to deny any support for clones of RHEL such as Rocky and Alma?
Indeed, we cannot claim support for all clone-distributions, as no matter how close to the original distribution they may be, we do not perform QA testing on them and the nuances that make these clones different than the original often introduce edge-cases that need to be accommodated for.

I'll note your request for support, but keep in mind that there are many such clone and each has its own devoted following; whether we will invest resources into testing them for support depends on many factors besides just popularity, so unfortunately I cannot mention if or when it would be supported.
In most cases it should "just work", but keep in mind taking this route may mean you need to handle some compatibility issues on your own.

Thanks
Fabian
Product Management Analyst @ Veeam Software

aj_potc
Enthusiast
Posts: 99
Liked: 19 times
Joined: Mar 17, 2018 12:43 pm
Contact:

Re: Linux incremental volume backups larger than expected

Post by aj_potc »

Thanks for your reply.

Unfortunately I haven't had any luck trying to discover the reason for the unexpectedly large incremental backups. Interestingly, for other Linux systems I'm backing up (mostly VMs), I'm not seeing the same problem I am on this physical server.

If it makes any difference, the system is using the XFS file system on top of md (software) RAID, and its role is a Web server. I suppose the software RAID wouldn't make a difference, as I don't think Veeam cares about the underlying storage architecture.

If anyone has had experience troubleshooting a similar issue, and was able to pinpoint a cause, I'd be happy to hear about it.
Any ideas about identifying the source of the changed blocks would also be appreciated.

Thank you.

PTide
Product Manager
Posts: 6200
Liked: 673 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Linux incremental volume backups larger than expected

Post by PTide »

@aj_potc,

Please share your logs via any fileshare of your choice.

Also please tell us more details:

1. Was it always like that (large increments), or it just started recently?
2. How exactly 'large increments' look like?

I mean, had you just dropped a 2GB file on the system and expected the backup to be 2GB in size but it turned out to be 3+ GBs? Please describe your scenario and observations.

3. Is there any kind of deduplication mechanism that might be shuffling blocks around on the disk thus causing the increment to grow?

4. What are your processed/read/transferred numbers from the job session?

Thanks!

aj_potc
Enthusiast
Posts: 99
Liked: 19 times
Joined: Mar 17, 2018 12:43 pm
Contact:

Re: Linux incremental volume backups larger than expected

Post by aj_potc »

Hi @PTide,

Thanks for your reply.

I did include logs in the case mentioned in my first post, and these were eventually analyzed by one of your engineers and his support manager. No issue was found with the Linux agent, and all appears to be running normally in that regard.

The incremental backup sizes have always been larger than expected for this physical server.

Daily incremental backups are typically 40-50 GB, even if little or no extra content is added to the server. Veeam's compression reduces this a bit, which helps. But, within the span of a week, my Veeam incremental backups for this server will take up about 250+ GB on my backup repository. This represents more than 10x the actual data growth rate for the server. So, as you can imagine, it certainly puts a dent in my repository capacity.

I can't imagine what data is changing so much on a Web server that stores static files. It's certainly not data being added. But I have no processes that would change existing data, either.

Thanks very much for any ideas!

Post Reply

Who is online

Users browsing this forum: No registered users and 17 guests