Backup hit 499GB not getting larger

[dukeminster1]

Hi Guys,

Wondered if you could help. We run a reverse incremental backup every night, which takes just over two hours and completes with no errors. It had been increasing steadily over the last few months. The size of the FULL backup file has now hit 499,371,600 KB and is the same every night. I usually copy this file to an external source and take it home with me. However, it has stopped increasing in size and I am a bit worried I am not backup everything. The file below it (we keep 25 restore points) is a vrb. (reversed incremental backup file) is also being accessed and modified every night and is growing in size - this wasn't happening before.

So my questions are:
1. Why has it stopped incrementing the full backup file at 500GB and can I resolve this.
2. Should I be backing up the reversed incremental file every day too?

Thanks in advance.

[Gostev]

Hi, Dave. It is normal for VBK not to increase in size, as incremental data is taking spots of those VBK file blocks that are leaving into VRB files. And remember that when in doubt, it is very easy to check if everything is fine by simply starting file level recovery from the latest restore point, and ensuring that all the latest guest files are there. Thanks!

[dukeminster1]

Thanks for your reply.

Ok I think I understand what you are saying, but why then has it increased steadily to that size over time and then suddenly stopped?

[veremin]

Hi Dave,

As mentioned, it might happen that backup file stops to grown due to incremental data occupying spots inside .vbk file. If I were you, I would just initiate file restoration procedure and destroy or confirm your doubt once and for all.

Thanks.

[Gostev]

Ok I think I understand what you are saying, but why then has it increased steadily to that size over time and then suddenly stopped?

Production workload behavior changes. Sounds like previously, you had lots of new data created daily (thus occupying new virtual disk blocks), while now it is mostly existing data being updated (thus modifying already occupied virtual disk blocks). For example, transaction logs of newly deployed servers growing on the newly created virtual disk may cause the observed behavior.