Thank you for this constructive argument

Have a nice day.

@markhewitt1978 Hi, thank you for your feedbacks!

We are aware that this limitation bothers a lot of users and we have plan to address that in the next major version of XO.

XO 5 was already a major improvement over its predecessor because it allows viewing and handling a much bigger infra.

XO 6 will go further in this direction by introducing a tree view and the possibility to edit and handle many objects at the same time.

@Danp That may not be directly to script but to the external environment: SMB works much better if cifs-utils is installed on the system, something that is present on our doc but might be missing in some install scripts.

We have no animosity whatsoever regarding these scripts but we prefer our appliances (or even manual installs from our documentation) because we understand much better what's going on and it's easier to replicate and fix the issues

Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome

Thank you all for your reports, should be fixed

https://github.com/vatesfr/xen-orchestra/commit/3cc9fd2782de353dbd866471a793366748c0c098

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/api): log instead of rejecting  non-strict schemas

Fixes https://xcp-ng.org/forum/topic/4439/plugin-transport-email-v0-6-0-broken

@rizaemet-0 Thank you, this is really interesting, it suggest that HTTP encryption in XO is a CPU bottleneck.

It should be alleviated in the future, because in a couple of month, all backup jobs should run in separate process, which will better distribute load on multiple CPUs.

FYI, this feature has been released

I'm thinking about it

Hey everyone!

The patch is finally here

Sorry for the delay

How to test?

1. Select the latest channel on your XO appliance
2. Upgrade to Xen Orchestra 5.43.2
3. Go to the Proxies page and either Deploy a proxy or upgrade the appliance of your existing ones

What's here?

• Full Backup
• Disaster Recovery

Known limitations/issues

Scheduled for Step 2 at the end of the month.

• Network configuration for the proxy appliance
• Delta Backup
• Continuous Replication
• Detailed logs, they are currently empty
• Restoring backups
  Work-around: create a normal remote (not linked to the proxy) connected to the same storage and import via the XO appliance

Thank you for your feedbacks

Indeed, there is a major issue with the fix, I'm on it.

Sorry for this

Answered on the XO forum, thank you

@johnarvid I was answering the ls problem, not the initial message of the thread

Backup issues should be self correcting, does the next run not fix the situation for you?

If not, you can take a look at the integrity of your backup files: https://xcp-ng.org/forum/topic/2994/check-backup-integrity/5

Maybe your remote is not mounted, you can try to disable/enable the remote.

I don't think I understand the question, it appears to me you want to do delta backups each day of the week but a full backup on Saturday.

Using a dedicated schedule with force full backup like shown on your screenshots is indeed the way to go.

@mbt Great! Thanks for your report and testing

Thank you all for your reports, should be fixed

https://github.com/vatesfr/xen-orchestra/commit/3cc9fd2782de353dbd866471a793366748c0c098

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/api): log instead of rejecting  non-strict schemas

Fixes https://xcp-ng.org/forum/topic/4439/plugin-transport-email-v0-6-0-broken

@alexander-0 Thank for this report, taking a look ASAP.

Should be fixed on master, please test and keep me posted

FYI https://github.com/vatesfr/xen-orchestra/commit/8e4c90129e2ce82cd1d4097005048c0564898e72

0 julien-f committed to vatesfr/xen-orchestra

fix(backups/DeltaBackupWriter): dont overwrite prepare/cleanup in constructor

Introduced in e69b6c4dc

@mbt A simple git pull --ff-only should do the trick.

Anyway, I think I found the issue

Nope, I don't see how this error can occur, are you up to date with master?

@deoccultist Not much I can add there, it looks like a system error between your XOA and the remote.

1. What kind of remote are you using?
2. Does this happen often?
3. Have you tried restarting xo-server or the OS?