Large VIB file on a small static server

[Lars-Peter]

Hello,
is there a way to get information about the daily incremental backup data/files from an Hyper-V virtual machine Backupjob?
Every day we have more backup data than expected and we would like to know, where it comes from.
Many thanks for your support,

Lars-Peter

[jochot]

Hey,

So I have a Server with arout 80TB of data, the vbk is 70TB large and the incrementals vary from 30MB to 1.66TB.
Now I had some problems with the Backup in the last time so I stopped it and had to do some changes on the server but nothing with the Job or the Backup chain.
When I start the Job, it creates a vib, so it should be incremental, but it grows like a vbk (it's transferred 6.7TB right now at 1,2x compression and read 7.9TB, so it doesn't look like an incremental).
I do not have space for another vbk on my storage, because I planned it with one vbk for that backup.
Also it apparently lost the CBT, are there any common issues with wich the CBT is lost? Maybe when you stop a backup or something? Afaik you need to get another full backup to restore the CBT?

Is there any way of knowing why it doesn't do a "real" incremental but rather fills the vib. file with all the data?

By the way, there is no way that there was that much data changed, how does Veeam behave when data is Moved on the Server? When I move 5TB from folder c:/something to d:/something is it copying the old data in the new location or is it just changing the metadata?
Anyway, here the blocklevel deduplication should come in right? To save me from storing the same data over and over again when it get's moved?

[PTide]

Also it apparently lost the CBT, are there any common issues with wich the CBT is lost? Maybe when you stop a backup or something? Afaik you need to get another full backup to restore the CBT?

Even if CBT had been lost, VBR would have performed a full scan of the VM's disks. Although backup would take more time than usual, only the changes would be transferred. Therefore if you could share your thoughts on why do you think that there is a chance of a not real incremental having been done, that would be great.

By the way, there is no way that there was that much data changed, how does Veeam behave when data is Moved on the Server? When I move 5TB from folder c:/something to d:/something is it copying the old data in the new location or is it just changing the metadata?

If the block has been overwritten on a guest file system, that will be seen as a change by CBT, thus it will get into the resulting backup file.

Anyway, here the blocklevel deduplication should come in right? To save me from storing the same data over and over again when it get's moved?

Yes, deduplication will work, however it won't catch all the duplicates since it works on a virtual disk block level, while the duplicates are on the guest file system.

Thanks

[b.vanhaastrecht]

Hello,

We have a Windows 2016 file server VM on ESXi 6.5 which generates a huge incrementals. On 3TB disk generates +200GB incrementals. De disk has 35GB left as free space. Could it be due to lack of space files are moved around and therefore generating a lot of cbt?

We see no other reason why there are so many changes.

Kind regards,
Bastiaan

[Andreas Neufert]

On the fileserver, what filesystem is used? Antivirus scans enabled (extrac compressed data temporary => disk changes)? Pagefile or Hyernation file on this disk? Memory dumps on the disk? Software Snapshot (Shadow Copy Services) enabled?

There are a lot of things happening in the background to optimize data access, jut by the operating system in teh background.
As we will just get reported what VMware will "see" happening on disk, there is little influence from the Veeam side.

On another note what is the ratio between "read" and "processed" in the job statistics for this VM?