You are not logged in.
When replicating a VM using option --replica=cbt in a quiesced hot backup, I realize that each time a quiesce manifest .xml file is created and a snapshot .vmsn file. Besides the vmware-*.log files. So the files get more and more.
Is it fine to delete these files in regular intervals from the VM directory?
Is it fine to exclude these files from replication?
Last edited by herrep (2021-09-27 12:24:56)
Yes, you can delete or exclude them. Nonetheless they are very small and can offer some info on every backup/ replica cycle. You could also move them to some subdir.
I run replica cbt with hot backup, so I assume it would be good to keep always the latest .vmsn file so that the replicated VM contains also the active state information. Is my understanding correct that in such a replicated VM only keeping the last .vmsn file makes sense? I wonder why all previous .vmsn files and all previous quiesce manifest .xml files are kept when there is already the next cbt cycle?
According to my understanding, the replicated VM does not allow to roll back to a previous CBT cycle. For this purpose, I would need to deduplicate backup the replicated VMs. Then I can access any CBT cycle. Is my understanding correct?
For the purpose of using the replicated (and registered) VM, I assume that none of quiesce manifest .xml file is necessary - they are only relevant for analysis. Is my understanding correct?
We said, you can keep "some info", we didn't mean that that it can be used to revert the VM to a previous state. In the end what you describe is just a default behaviour: (c)XSIBackup copies anything that it can from the source VM. Implementing some option, default or user set, that allows to keep the target dir cleaner is at this stage of development something aesthetic. We will do it sooner or later, still we have too many important things to address.
Thanks for clarification. Just to make sure: When I run --replica as hot backup without shutting down the VM during replication, I assume that .vmsn contains the memory state of the machine. Therefore, the old .vmsn files are not of any use as I cannot revert the VM to a previous state, but the last .vmsn is essential if I want to continue right after the point of having performed the replication. Therefore, I can delete all "old" .vmsn files in the replicated VM directory, but should keep the last .vmsn file. Is this correct?
(c)XSIBackup isn't currently compatible with taking memory snapshots, thus the .vmsn file is mostly useless in every case, you don't need it.
The following question is: why does (c)ESXi create a .vmsn file then when not taking a memory snapshot?. That's something (c)VMWare should answer.
Good to know that non memory snapshots are taken by xsibackup. Am I right that --backup-how=hot is equivalent to restoring the disk state at the point of the backup/replica, but the memory state is lost, like when switching of the VM without shutdown? However, this should have no impact on cold and warm backups, as the VM is shut down, thereby having no memory state at all.
There may be people for which backing up the memory could be useful. We'll revise the posibilty to add the memory, still (c)VMWare is progresively locking out (c)ESXi, it may not even be possible in latest releases.
I would assume that it implies a risk in performing hot backups if the memory state is not saved. But probably I did not fully understand the way how the hot backup/replication is performed. Therefore, I would appreciate if you could shed some light onto hot backups in conjunction with not considering the memory state.
I believe we are not fully engaged in a meaningful debate.
Why do you believe that the memory state is crucial to a backup?
The memory state are the contents of the memory (RAM) at the time to take the backup/replica. RAM memory is volatile, it is only meaningful at a given nanosecond in time (depending on the CPU frequency).
Memory is saved when you want to suspend a PC and return to it as it was at the time you suspended it. Per instance when you fold a lapton down. It's just a way to make it not consume electricty while actually turning it off and be able to return to it's working state as if it had never been switched off, keeping all your applications and unsaved data as you left it at the time to suspend it.
When you backup a server, you want it to contain data written to disk at a given point in time and you want it to be consistent. You don't usually care much about the contents of the memory, unless you have very picky and especific reasons for it, which is not the case 99.9% of the times.