@ph7 Ok, thanks. But the most important will be to do this test while some VMs are missing from the backup restore page (if it happens again)

@Pilow Hi, As you already tried a patch on your server, can you try to also update the line 110 of @xen-orchestra/backups/_runners/_writers/_AbstractAggregatedRemoteWriter.mjs - const scheduleId = this.#props.scheduleId + const scheduleId = this.#props.schedule?.id ?? this.#props.scheduleId Thank you

Still no cleanup [image: 1775113648155-screenshot-2026-04-02-at-09-07-11-backup.png] [image: 1775113652163-screenshot-2026-04-02-at-09-06-13-backup.png]

I think I added it after the video ^^ (between the recording and the official release)

@wgomes yup thanks for bumping this topic, still having the problem too

@abudef I've been there, here is my vision on the topic. in terms of RETENTION of the schedule, if you put 21, not using the FULL BACKUP INTERVAL in the job, you will get : one full and 20 subsequent deltas. on the 22nd point, a delta will be done and the oldest delta (the one just next to the full) will be merged in the full. its like a forever incremental. Put 7 in FULL BACKUP INTERVAL, and every 7 days (if it runs once every day), it will make a full. other way to do it : as you told, two schedules, with forced full on sundays. difference between the two ? you really choose wich day the full occurs. in the first way, the full is "7 days after the chain begins" do not mix these two way of configuring, you would have unnecessary fulls in your chain. in terms of LTR, @florent and @bastien-nollet recommended me this : if you use LTR (lets says 14Daily, 4Weekly, 2Monthly), keep the SCHEDULE retention to 1 the LTR parameters will keep the retention points as intended try not to mix with FULL BACKUP INTERVAL LTR is still early, because i would like the WEEKLY/MONTHLY/ANNUALY to always be fulls or specific merged fulls, this is not the case... it is still not clear, as you can't choose it, which day is the WEEKLY (sunday ? monday ?) the MONTHLY (1st ? last day of month ?) trial & error mode activated.

Ok just read the code and found my answer It was a typo it is repo-gpgcheck not repo_gpgcheck repo_gpgcheck = (None if getStrAttribute(i, ['repo-gpgcheck'], default=None) is None else getBoolAttribute(i, ['repo-gpgcheck'])) gpgcheck = (None if getStrAttribute(i, ['gpgcheck'], default=None) is None else getBoolAttribute(i, ['gpgcheck']))

had the same on one pool that needed 97 updates. RPU was going great, but couldn't migrate VM post-upgrade it is a pool of 2 hosts, second hosts still had 97 patches to pass... even if RPU was finished. we waited 10 min and the 97 patches disappeared, and then we could migrate the VM

Different use cases: Ceph is better with more hosts (at least 6 or 7 minimum) while XOSTOR is better between 3 to 7/8. We might have better Ceph support in the future for large clusters.

@User-cxs peut etre un clnflit IP ou la VM prenait l'IP du master... courage pour la suite !

@DustinB If it hangs right after detecting the disk, it could be a bootloader or filesystem inconsistency from the snapshot state. Can you try booting the VM with a recovery ISO to check disk integrity or rebuild the bootloader?

@dlgroep Thank you, we will take thin/thick token into account and use 'claims' part for other properties.

To add a bit more detail on the upgrade path: strictly speaking, you do not need to apply outstanding 8.2 patches before upgrading. When you upgrade to 8.3, you are replacing the entire base system with the 8.3 release which already incorporates everything from the 8.2 patch stream. Any 8.2 patches you hadn't yet applied will simply be superseded. That said, applying them first is still a reasonable approach if you want a clean upgrade history and a fully-patched 8.2 baseline before jumping to 8.3. A few things worth checking before you start on a production pool: Check VM compatibility. Run a quick review of your VMs for any that might have specific OS or toolstack dependencies tied to 8.2. Most guests upgrade cleanly but it is worth knowing your environment. Use rolling pool upgrade if you have more than one host. XCP-ng supports rolling upgrades: you migrate VMs off each host, upgrade it, rejoin the pool, then proceed to the next. This maintains VM availability throughout the process. The XO interface handles this workflow if you have XOA. Back up before the jump. Export critical VM configurations or snapshots beforehand. If you use Xen Orchestra for backups, trigger a manual full backup job before starting. The upgrade itself via yum is straightforward: add the 8.3 repo, yum update, reboot. The toolstack and XAPI will handle pool registration after the host comes back up. After upgrading all hosts, run the post-upgrade checks from the docs (pool metadata sync, storage rescans) and verify HA is healthy if you use it.

@AtaxyaNetwork Merci becuoup pour ce retour. Je vais compléter l'article dans ce sens.

@Danp Okay thanks you

@MathieuRA said: @ph7 @acebmxer Hi, regarding your backups which do not appear on the XO5 restore page, I suggest you to open a new topic so that this one remains focused on XO6 dashboards Once I updated back to master are restore points are visible again. Issue only appears with this test branch.