@julienXOvates Yes, it is resolved. Thank you.

Looks like the new build keeps retention snapshots in single VM instead of creating multiple VMs. Wasn't able to replicate the issue.

I thought that the update wouldn't solve the problem because my build was still much newer than this thread.

Hi there. Using XCP-NG 8.3 with XO from sources. It was 6a5eb1205 (already updated it).
There was active backup task with "temporary disabled" hover on cancel button. But nothing active in task menu.

After shutting down "Importing....." VM and rebooting the host for a second time, VM starts again. VM had autostart ON and "continuous replication" tag. Maybe the "lock" for disabling the autostart is applied only after the task is done?

Today I will try replicate the issue with some testing VM.

Today similar problem. During CR, the target host suffered powerloss. After recovery, VM (name "Importing.......") booted on backup host. Boot drive was already copied before powerloss.

@peder Did you resolve this issue or report it on github (can't find it)? I have same issue reattaching NFS and iSCSI SR. After clicking reattach button, the SR is created but with no PBD. Creating new SR is fine. I have to use xencenter for reattaching.

@julien-f Backup files check found no problems, so I tried to restore again and it works. No changes or updates in XO, no changes on vhd or json files (same dates and sizes). Only think I did was detach and attach backup repository (settings - remotes) which I tried before with no luck.

Trying to restore delta backup in Orchestra v5.70.0 build from sources.

Oldest backup
November 8, 2020, 11:20:01 PM

Latest backup
November 23, 2020, 11:20:01 PM

Available Backups
delta 18

Web UI throws error:

ENOENT: no such file or directory, open '/run/xo-server/mounts/26a365a5-fff3-4ad9-b9af-f041f04ed42b/xo-vm-backups/b487c411-18b8-1de3-55d3-9ac6480d4732/vdis/638f3d43-3ed8-4906-a78f-b98184681a0e/6f9e79f0-fbc7-4045-acca-44cebbe1c7b4/20201106T222001Z.vhd'

On Orchestra VM:

root@xoa:~# ls /run/xo-server/mounts/26c5174a-1dda-4d2a-a627-543b0d8aeb4b/xo-vm-backups/b487c411-18b8-1de3-55d3-9ac6480d4732/vdis/638f3d43-3ed8-4906-a78f-b98184681a0e/6f9e79f0-fbc7-4045-acca-44cebbe1c7b4 -l -h
total 408G
-rw-r--r-- 1 root root  20G Nov 24 01:23 20201108T222001Z.vhd
-rw-r--r-- 1 root root  31G Nov  9 23:29 20201109T222001Z.vhd
-rw-r--r-- 1 root root  34G Nov 10 23:30 20201110T222001Z.vhd
-rw-r--r-- 1 root root  43G Nov 11 23:32 20201111T222001Z.vhd
-rw-r--r-- 1 root root  34G Nov 12 23:30 20201112T222001Z.vhd
-rw-r--r-- 1 root root  35G Nov 13 23:30 20201113T222001Z.vhd
-rw-r--r-- 1 root root  16G Nov 14 23:24 20201114T222001Z.vhd
-rw-r--r-- 1 root root  15G Nov 15 23:24 20201115T222001Z.vhd
-rw-r--r-- 1 root root  30G Nov 16 23:28 20201116T222001Z.vhd
-rw-r--r-- 1 root root  14G Nov 17 23:23 20201117T222001Z.vhd
-rw-r--r-- 1 root root  36G Nov 18 23:30 20201118T222001Z.vhd
-rw-r--r-- 1 root root  34G Nov 19 23:30 20201119T222001Z.vhd
-rw-r--r-- 1 root root  36G Nov 20 23:33 20201120T222001Z.vhd
-rw-r--r-- 1 root root  12G Nov 21 23:23 20201121T222001Z.vhd
-rw-r--r-- 1 root root  12G Nov 22 23:24 20201122T222001Z.vhd
-rw-r--r-- 1 root root  12G Nov 23 12:21 20201123T111720Z.vhd
-rw-r--r-- 1 root root 603K Nov 23 12:38 20201123T113818Z.vhd

File is really missing. I was not messing with .vhd files on filesystem (actually this is the first time I saw where they are). Just remember lowering retention policy (through web UI) couple days ago if it's relative.