Brief rundown on capabilities and features of veeamsnap module?

[mikeely]

I've only been able to find the most basic descriptions of how the veeamsnap module functions, mostly along the lines of "it creates a snapshot" level of detail. The next level of detail I've been able to find is the source code itself on github which makes for a heavy lift to answer this question.

What I'm hoping for is a bit more detail than what I've found so far. How does veeamsnap work, step-by-step?

Thanks!

[HannesK]

Hello,
maybe you can explain the background of your question? Are you trying to solve any specific issue, or are you just interested how it works?

What level of detail do you need, to solve your problem?

Please keep in mind, that it also takes us time and resources to write down such detailed descriptions

Best regards,
Hannes

[mikeely]

Hi, thanks for getting back to me. I also appreciate your concern regarding use of time, so hopefully this effort would be to update regular documentation rather than simply leaving something that will eventually be buried under more recent posts on the forum

I'm asking because before we entrust backing up our production infrastructure to Veeam we would be vastly more comfortable knowing how the essential component of the process (veeamsnap) works. For example, the documentation on how ESX snapshots are made is well documented (that's just one example) so when the Veeam documents say "an API call is made to vSphere requesting a snapshot be made of the target VM" a Veeam end-user can investigate that to their own satisfaction, to say nothing of the satisfaction of their managers and executives. Such knowledge also helps the customer troubleshoot if something breaks.

The level of detail I'm looking at need not be to quite the satisfying level of detail as the VMWare document, but at minimum would be something along the lines of this example (which I've completely made up because I don't actually know how veeamsnap works):

1. A call to veeamsnap_get_volume_map (documented here) is made for all volumes to be snapshotted.
2. This result is compared to the existing CBT map which is stored in /path/to/map in the format special_btree_we_invented (link to github repo for special_btree_we_invented).
3. A second volume is mounted and all dirty (changed) blocks are written to that volume.
4. The output of the call to get_map replaces the previous CBT map which is backed up for rollback purposes (see this KB article for rollback procedures).
5. The sparse volume is unmounted and transferred to the Veeam backup repository.
6. Once the transfer is complete and verified, the sparse volume is deleted.

[HannesK]

Hello,
well, it's the first time ever (globally) someone is asking for that kind of documentation. So we are thinking about it, but I cannot promise any timeline.

What we do is creating a copy on write snapshot (COW). The CBT is RAM based and reset with each reboot / unload of the module (see user guide)

If you do not trust the veeamsnap module, then you can also use the agent without the module. Maybe that helps.

Best regards,
Hannes

[mikeely]

Hi, thanks again for the reply. It's not so much a question of trust as it is one of us being sysadmins wanting to know what our servers are doing. The description you gave is helpful and probably enough for now but it would definitely be helpful to include at least a similar gloss in the official documentation.