@ChuckNorrison Ah, thnx for updating... I edited my servers, hope to see some speed improvements!

Hi,

I'm very interested in trying this out.
Except I can't find how I should change the master URL?

In XO when I click on the disconnect button in the pool view I receive an error.

It still backupped my VM...

I created a workaround now.
I added a new tag to the source VM (CRbackupBLOCK). This tag is transferred over directly.
The backup job on the receiving server has this tag blocking the VM from being backed up.

Hi,

I experienced something similar.
I created a CR job and made it run. It's ~6TB and takes longer that a day (so I had to edit the timeout value). On the receiving end the backup job (using smart mode) started and was also backing up the CR VM (while it was still being transferred for the first time).

I checked the new VM and it dit NOT have the CR tag. After the job completed it had the CR tag.
Shouldn't it get the tag as soon as the VM is created to prevent it from begin backuped yet again?

I'm using XOCE xo-server 5.68.0 xo-web 5.72.0

In our case it was (fairly certain) 300 GB before and 600 GB after on EXT3 Storage.
I don't know how full the disk was... but we needed to expand is for a reason, so it should have been close to full I guess

We increased the disk size, everything was fine, until the error popped up a week later, then started to search and found this thread...

I can confirm that Alex's workaround does work.

Hi,

I know this is an 'old' topic, but would like to confirm this bug as we have the same with one of our clients servers, days after expanding the VM disk.

Stil need to move the old backup (it's copying as we speak) and assume after I delete the original backups it will work again.
Will need to see if this still happens in the latest version of XOCE and in XOA.