Rep Job Increased over 5x Normal Size Last Night

[soupergrover]

Hi All,

I have a Win2k3 VM with the following setup

Disk 1: 20GB Total/15GB Used/Thick
Disk 2: 210GB Total/176 Used/Thick

Typical Transferred size for this replication job is 1.5 - 2GB daily. Last night, for some reason I am trying to determine, it transferred 10.7GB. Most of the increase appears to have been on Disk 2, which is a data drive full of file shares.The amount read is typically 3-4GB. Last night it was 14GB. When I compared drive size changes for the past 48 hours, I saw a 2GB drop and then it rose again 1GB, but nothing drastic that sticks out.

What kind of things could make the transfer jump like that? If I move a large directory from one folder to the next, but on the same drive, would that do it? I haven't tried an sdelete yet because I didn't see any evidence of a change in disk usage. Any ideas?

Thanks!

[Andreas Neufert]

Block changes are in most cases not inline with file data amount changes.

Defragemntation runs are likely cause high block changes without to change used data on disk.

[soupergrover]

HI Andreas. Thanks for the reply.

Block changes are in most cases not inline with file data amount changes.

Does that mean if I move stuff from folder to folder on the same drive the blocks don't change and therefore Veeam doesn't care?

Defragemntation runs are likely cause high block changes without to change used data on disk.

No defrags were run on the drives yesterday. What about an AV scan? Could something up with the scan cause it? I'm pretty sure when I've run full scans in the past it didn't make a difference.

[Andreas Neufert]

Cut and paste on same vilume do not likely cause a change on block level besude metadata.

AV normally do not change anything. Maybe they extract zipped data on temp folder.

At the end you need to check in your VM what the root cause was.
Maybe Windows Event viewer is hdlpful. Maybe Fule chsnge time stamp

[soupergrover]

Nothing in the event viewer. Checked Application, DFS and System logs. Nothing out of he ordinary there.

The sizes I poted above are from withing the VM using the Windows tools. I think we have established that no data sizes have really changed. What kinds of tools or processes cause a lot of HDD activity or block level manipulation (besides a defrag)?

[foggy]

Someone could upload some data and immediately delete it, prior the backup started. This thread can also give you some hints.

[soupergrover]

Someone could upload some data and immediately delete it, prior the backup started. This thread can also give you some hints.

Thanks for the link, Foggy. I looked at it real quick and that is for a backup job. These are replication jobs. I'll still read through it, though, as it may mention something I haven't thought of yet.

I don't think anyone has uploaded and then deleted anything that large. I have the HDD monitored for space usage, and the graph doesn't show any large changes in the past 72 hours (this happened almost 48 hours ago now). It has gone from something like 36GB used to 34GB used and back up to 35GB used. It's slowly creeping up again, but nothing very noticeable

[foggy]

Most of the hints mentioned there still apply to replication jobs.

Btw, was it just a regular job run and the job ran normally on previous days? Changed blocks increase could be caused by a longer period since last replication cycle...

[soupergrover]

Btw, was it just a regular job run and the job ran normally on previous days? Changed blocks increase could be caused by a longer period since last replication cycle...

Normal job. This job occurred Tuesday evening. Monday job was about 800MB since it was a national holiday here nad we were not open.

For the record, I did move the job to 90 minutes later than normal due to some late hour working this week by some external parties on one of our systems. We are all gone by 6PM. This job usually runs at 7PM for about 20 minutes. I moved it to 8:30PM as of Tuesday (when this large rep happened) and the job took an hour. On Wednesday, it transferred 4GB. Last night 3GB which is more in line with what I expect. Pushing the job ahead 90 minutes shouldn't cause THAT drastic of an increase should it?

[foggy]

No, there should be some activity that caused that.

[Andreas Neufert]

You can install Veeam ONE to analyse the disk I/O. If this happens again, you can at least identify the time of this change block burst. And over time you can maybe identify a pattern that happens again and again.

Please look as well in the Windows Planned Tasks,maybe you can identify something there.
As well look at your antivirus solution some also came with disk optimization (defrag and putting frequented data on inner disk spindle area).