#1 2019-03-12 01:06:45

NextLevel
Member
Registered: 2019-03-11
Posts: 33

OneDiff ends in a registering loop

Running a backup with OneDiff ends in an infinite loop of the _XSBAK register task. Causes the host to stop responding in the web client until I manually unregister the _XSBAK VM .

Unregister VM	
TestW2k3_XSIBAK
root	03/12/2019 01:53:27	03/12/2019 01:53:27	Completed successfully	03/12/2019 01:53:27
Download VMXConfig	None	VC Internal	03/12/2019 01:53:25	03/12/2019 01:53:25	Completed successfully	03/12/2019 01:53:25
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:53:25	03/12/2019 01:53:25	Completed successfully	03/12/2019 01:53:25
Download VMXConfig	None	VC Internal	03/12/2019 01:53:15	03/12/2019 01:53:15	Completed successfully	03/12/2019 01:53:15
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:53:15	03/12/2019 01:53:15	Completed successfully	03/12/2019 01:53:15
Download VMXConfig	None	VC Internal	03/12/2019 01:53:05	03/12/2019 01:53:05	Completed successfully	03/12/2019 01:53:05
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:53:05	03/12/2019 01:53:05	Completed successfully	03/12/2019 01:53:05
Download VMXConfig	None	VC Internal	03/12/2019 01:52:55	03/12/2019 01:52:55	Completed successfully	03/12/2019 01:52:55
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:52:55	03/12/2019 01:52:55	Completed successfully	03/12/2019 01:52:55
Download VMXConfig	None	VC Internal	03/12/2019 01:52:45	03/12/2019 01:52:45	Completed successfully	03/12/2019 01:52:45
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:52:45	03/12/2019 01:52:45	Completed successfully	03/12/2019 01:52:45
Download VMXConfig	None	VC Internal	03/12/2019 01:52:35	03/12/2019 01:52:35	Completed successfully	03/12/2019 01:52:35
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:52:35	03/12/2019 01:52:35	Completed successfully	03/12/2019 01:52:35
Download VMXConfig	None	VC Internal	03/12/2019 01:52:25	03/12/2019 01:52:25	Completed successfully	03/12/2019 01:52:25
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:52:25	03/12/2019 01:52:25	Completed successfully	03/12/2019 01:52:25
Download VMXConfig	None	VC Internal	03/12/2019 01:52:15	03/12/2019 01:52:15	Completed successfully	03/12/2019 01:52:15
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:52:15	03/12/2019 01:52:15	Completed successfully	03/12/2019 01:52:15
Download VMXConfig	None	VC Internal	03/12/2019 01:52:05	03/12/2019 01:52:05	Completed successfully	03/12/2019 01:52:05
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:52:05	03/12/2019 01:52:05	Completed successfully	03/12/2019 01:52:05
Download VMXConfig	None	VC Internal	03/12/2019 01:51:55	03/12/2019 01:51:55	Completed successfully	03/12/2019 01:51:55
Reload	
TestW2k3_XSIBAK
VC Internal	03/12/2019 01:51:55	03/12/2019 01:51:55	Completed successfully	03/12/2019 01:51:55
...

Running on a ESXi-6.0U3-10719132. XSIBACKUP-PRO 11.2.3.

Very bad.

Offline

#2 2019-03-12 10:13:20

admin
Administrator
Registered: 2017-04-21
Posts: 1,366

Re: OneDiff ends in a registering loop

There's nothing like that registered before, contact support to examine the details of your case.

Offline

#3 2019-03-13 01:27:46

NextLevel
Member
Registered: 2019-03-11
Posts: 33

Re: OneDiff ends in a registering loop

Well, I don't care any longer because OneDiff is a total No-Go.

Seriously, leaving a permanent snapshot on a productive vm ? Don't you know that an active snapshot caused a  performance disadvantage up to 40% on the drive throughput?

Just to be sure I've made a short test with CrystalDiskMark 1Gb Seq Read/Write:
- without snapshot ~1550MB/s read/write,
- with the snapshot ~1000 MB/s read/write.

That's why you should never leave a snapshot longer as necessary.

Yes, OneDiff is a cheap way for having differential replication, but costs you a way too much in performance.

Maybe XSIDiff will work better for me... currently testing...

Last edited by NextLevel (2019-03-13 02:19:19)

Offline

#4 2019-03-13 16:49:19

admin
Administrator
Registered: 2017-04-21
Posts: 1,366

Re: OneDiff ends in a registering loop

We have never seen this behaviour, but given the fact that you seem to be using a Windows 2003 VM, which is quite an outdated OS, you should investigate whether the version of VMWare tools you are using is conveniently updated.

OneDiff is used by thousands of people around the globe with optimum results.
VMWare warns about long chains of snapshots being kept in production VMs, but a single snapshot should not hurt performance.
Maybe your test was too short, we don't get the same results. When you have one active snapshot in a VM, the VM kernel saves data to the snapshot instead of to the base disks, which does not affect throughput much. It is the moment of coalescing snapshot data with the base disks that may cause a big load, especially on long chains of snapshots.

XSIDiff is a binary used by OneDiff but it's not a differential tool.

Offline

#5 2019-03-14 00:18:51

NextLevel
Member
Registered: 2019-03-11
Posts: 33

Re: OneDiff ends in a registering loop

I've been doing these tests since ESX 3.5 and it's getting better and better from version to version, but the performance loss is still evident. Even if I use W2k8_R2 with current VMWARE tools: the throughput breaks down immediately when a snapshot is active.

However, ultimately, I was able to determine that the only approach that fits our needs is via XSITools.

Offline

#6 2019-03-14 20:05:54

admin
Administrator
Registered: 2017-04-21
Posts: 1,366

Re: OneDiff ends in a registering loop

XSITools is by far the most advanced tool we offer, as it combines deduplication with zero awareness plus differential copy. Even though it uses a big block size 10M, 20M or 50M, it can achieve a high level of data density, mainly due to backing up the same set of VMs recurrently.

Offline

#7 2019-03-15 21:27:28

NextLevel
Member
Registered: 2019-03-11
Posts: 33

Re: OneDiff ends in a registering loop

admin wrote:

We have never seen this behaviour, but given the fact that you seem to be using a Windows 2003 VM

Do not blame my 2003 machine. It's still the fastest of them all smile

admin wrote:

Maybe your test was too short, we don't get the same results

Not to make me guilty for superficiality, I repeat all the tests again with a freshly installed ESX Server 6.0. With 2012 server, with 2008R2 server, with 2003 server.

All run on an NVME datastore with the latest VMtools.

The result is still the same.

Test1
Test4
Test2
Test3

If you say that you do not get the same results, PLEASE enlighten me: What have I missed in the last 10 years?
I would be overjoyed to use OneDiff if that performance loss of snapshots were not so big. Really, I mean it

Because the registering loop does not happen if I use the --options=unreg-xsibak.

Last edited by NextLevel (2019-03-15 21:32:46)

Offline

#8 2019-03-16 16:15:13

admin
Administrator
Registered: 2017-04-21
Posts: 1,366

Re: OneDiff ends in a registering loop

Those tests are valid for your hardware and the amount of data used to perform the test, which don't correspond to the I/O figures of an average server in production.

Since ESXi caches as much data as it can in RAM, real usage figures for real situations don't differ that much, in fact, most of the times don't differ at all.

You are publishing figures obtained in one extreme of a Gaussian distribution to explain the whole distribution.

The registering loop does not happen because the _XSIBAK VM is not registered when using that flag.

Offline

#9 2019-03-16 17:58:55

NextLevel
Member
Registered: 2019-03-11
Posts: 33

Re: OneDiff ends in a registering loop

admin wrote:

Since ESXi caches as much data as it can in RAM, real usage figures for real situations don't differ that much, in fact, most of the times don't differ at all.

Yes, you are right, except for a Remote Desktop Server. It "feels" the 4k32Q breakdown extremely . When a snapshot is activated, the users begins to complain why is it so slow today....

However, I like XSIBackup more every day.

Offline

#10 2019-03-17 13:09:16

admin
Administrator
Registered: 2017-04-21
Posts: 1,366

Re: OneDiff ends in a registering loop

Thank you for your support!.
You may be able to work that around some other way, like using a different kind of backup for RDP desktops.

Offline

Board footer