@ronivay that was it

It's exactly the same process for any other backup.

That's precisely the difference: a delta backup is stored in a remote, a CR is stored in an SR.

Becouse xoa backup is painfully slow... it's good for CR but for full vm backup, let's say it's unsuitable... on my 1Gb lan, full vm backup (DR or Copy) from xcp1 to xcp2 I have about 10-15Mb/s. This is the topic I've asked many times on this forum. And guys from vProtect brag that the speed im much better on their soft due to CBT not vhd delta - which I'll check in a while.

@tony Yes, that's the setting I was talking about. OKay. I've no idea what VIF-locking is, so I'll leave it there! Thanks again.

Personally, I wouldn't touch anything regarding XVA generation, it's deep into XAPI code. Rely on delta backup in general, it's better.

@akurzawa said in Wrong timestamp on snaphot: Hi It'a an important to know exact time of vm and snapshot - eg when recovering for an example a Active Directory or sql database. When doing so, someone can believe that restores the data from {the time visible in name}, because can be unaware of possible offset of zulu time. You already have the exact time If you aren't aware of an ISO standard format date, it's another story. But this is really standard and universal way. I suppose you meant "misinterpreting the snapshot time" which has NOT the same meaning than "incorrect time".

you can follow the fix is in this pull request: https://github.com/vatesfr/xen-orchestra/pull/5085 nraynaud opened this pull request in vatesfr/xen-orchestra closed feat(import/ova) allow import of gzipped vmdk disks. #5085

@karlisi said in Interrupted CR task - what now?: Automatically deleting incomplete VMs can be dangerous This is an example - don't take it too strictly. I'm talking about exaclty the above problem. I was not aware of it. No information about the problem and this is the exactly the real problem.

That's what I do now - I'm disabling this backup task for 2nd and 4th week.

Check host logs to understand why. Maybe those VHD were attached to the control domain or something like that.

@akurzawa xo-server is not explicitly multi-processed, but it uses async IO calls in Node which should lead to multi-threaded operations. Anyway, we are currently working on reimplementing backups for the proxy and it will eventually lead to using multiple processes. These changes will at the end be merged back to xo-server as well.

OK the tasks (it been 8 hours since I've checked) are gone, but the VHDs localted on backup server's localstorage remains. QUESTION: How to delete VHDs that are not realted to any vm? I think it will not be deleted automatically. EG. For example - I've deleted "Atlas" VM, but big atlas VHD remains on BackupHost's local storage: [image: 1581667660068-666ed028-c8e0-4ae7-86f3-1a307f7eee76-image.png]

If you create two separated jobs. One for the CR and one for the Rolling snapshot they will not interfere.

Yes, I would try that

Hi @akurzawa, this would be quite a big feature, please open an issue if you have something precise in mind (a list of possible actions, what could trigger a workflow, ideally some use cases that couldn't be done without it, etc.). Also, a lot can probably already be done with XO's Web Hooks, xo-cli and a third party workflow tool in between.

Repair is just replug the pbd. Of course you can do that with XO

I can put the script everywhere - but I want to avoid non standard config. In case of failure of {system} I'm reinstalling it, and restoring config from file. I don't need to remember that I've put some fancy staff somewhere on the lan.