Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

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.

Exactly!. --enable-cbt and --reset-cbt just save you from the hassle to have to edit the .vmx manually or add the options via the GUI. Also deleting the .xsi dir is a must to prevent problems. The .xsi dir will be created automatically if it does not exist.

Yes, you are right in that the VM state should be considered when running that argument. CBT feature is just weeks old, it lacks some refinements that will be added in next versions.

a) [b]_XSIREP[/b] VMs are filtered out. You would need to rename them or wait until we create a switch to override this behaviour. We'll do it in next release 1.5.1.2. We'll most probably just waive the filtering when using REGEXP.

b) We'll check this and eventually fix any bugs.

c) We'll check this and eventually fix any bugs.

The above described recommended procedure, namely: create a replica and then backup the replica, is something we recommend since years ago from the times of our former solution (c)XSIBackup-Classic. The reasons are obvious and have alredy been explained many times.

Nonetheless, as you start to add variables to the equation, you must take care not to fall into any logical pitfall. Per instance: you must take into account that the original CBT information will not be valid in a newly registered VM cloned from the original one. In fact the cbt flag will automatically strip any CBT/CTK related information from the target VM.

Thus, if you want to in turn use CBT from the cloned VM, you will have to reenable CBT in it, still it will only be valid until the following CBT cycle is completed, as the CBT information will be again stripped from it.

As a result of the above dialectical discourse, you will easily deduce that you can't chain CBT due to the fact that CBT is accounted at a host level, thus any CTK files cloned from other host will be invalid.

[b]Conclusion[/b]:

Replicate using CBT and backup without it. Given the fact that your replica is out of the production host, that shouldn't matter much.

--enable-cbt is just a helper, if the default behaviour does not suit your needs, just enable CBT manually.

[url]https://www.vmwarearena.com/enable-change-block-tracking-cbt-for/[/url]

We will improve the helper function in some future release.

Just use the installer when upgrading

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.

In these cases you just need to run --reset-cbt, no need for --enable-cbt, in fact both arguments produce the exact same result.
You just need to delete the .xsi dir in the source VM folder. Some further integration, as you suggest, would be to allow --reset-cbt to do that for you, still we decided to keep that folder as it contains some vital information on what was done before, maybe renaming it would be the simplest and wisest thing to do.

CBT feature is new, it was introduced this summer. We still have to produce some posts on some of the situations you may run into, like the one you describe.

Thank you for your feedback.

It's all simpler than that.
You want to register the VM to some (c)ESXi host?: no problem.
Replicate to some (c)ESXi host that has the NFS volume attached to it as a datastore.

That is something managed by (c)ESXi internals, nothing to worry about.

What version are you using?
Have you updated the installation to latest version?.
There are some versions of (c)ESXi that require latest version. Please do update and try again.
Please use the installer, don't just copy the xsibackup binary, there are new binaries in he package.

You just have to create compounded jobs, per instance starting at 900..
Job 901 comprising jobs 101, 102 and 103 would be something as simple as:

101
102
103

Or with absolute references

/scratch/XSI/XSIBackup-DC/etc/jobs/101
/scratch/XSI/XSIBackup-DC/etc/jobs/102
/scratch/XSI/XSIBackup-DC/etc/jobs/103

Then invoke job 901 from the cron

You can off course combine them depending on the return code of the job

/scratch/XSI/XSIBackup-DC/etc/jobs/101 && /scratch/XSI/XSIBackup-DC/etc/jobs/102

The above example would run job 102 in the event that the return code from job 101 would be 0

The order they are in the inventory file:

/etc/vmware/hostd/vmInventory.xml