Due to problem with XAPI and metadata import, I decided it's more safe to write ourselve a solution to avoid use of those metadata. XAPI team told me that the code around this is not in a good shape...
So postponed for Monday. Sorry guys, there is some stuff we can't guess before we got trouble inside XAPI ^^
edit: at least our QA pass is useful ^^
@mlnews Problem is also in next XenServer version. So we'll have better luck to write our own solution/workaround for this!
You forgot to git pull to get last changes 
Made a test by using the "old" Delta backup first with a retention of 3 (stopped after 6 manual calls):
As you can see we got 2 full disks rolled. Then upgrading to the new system and restart the backup:
Old files are correctly "garbage collected" 
BTW, you got 15 days of Premium trial by default with XOA.
If you want to test it, that's a good way (and if you finished the trial period, contact me, I'll unlock another 15 days).
@DustinB3403 That's it: you said 3 backups max, you got 3 backups. You can restore any of them.
If you choose the restore the full: we'll import the full.
If you choose to restore the first delta: we'll import the full then import the delta.
Etc.
@anonymous There is (mainly) 2 branches:
stable (which is stable 
)next-release (which is like a beta branch)To be sure you are on stable, go inside both xo-web and xo-server folder and do a git checkout stable. Then, you need to rebuild with npm i and npm run build.
For me, it's mainly XO when talking about sources, XOA the appliance. But XOS if you like, it doesn't matter
I would say: use XO to backup your VM running XO (whatever using XOA or sources). Inception eh?
About the install itself:
/var/lib/redis)leveldb database: probably inside /var/lib/xo-server/data/leveldb.If you backup those 2 db's + the config file, you can even start a new install of Xen Orchestra, and retrieve everything (configured servers, ACLs, backup jobs etc.)
Xen is purely LF, but also the toolstack which made XenServer what it is. Eg, XAPI is also a LF project
So +1 from the Scott's comment.
Removed, totally replaced by a new one from scratch (from design to framework)
edit: replaced. Not removed for ever ^^ Won't sell XO without a web client ^^
This number will give you better looking support team, faster response time and a lot more! So remember, dial 0118 999 881 999 119 725...3!
You should see something in the xo-server output right when you trigger the backup job.
I'm removing the word "Terminated" by "Finished" ASAP.
There is maybe a notion of "unexpected finish" for "terminated" word. In French, "Terminé" means "finished". That explains why one of the dev use this word
Can you please use our forum for those requests? I can't be everywhere at the same time and my answer time would be far longer outside XO forum.
Hi,
What kind of host metadata you would need to backup?
As you can see, you are not the first: https://bugs.xenserver.org/browse/XSO-44
Import/Export speed is a nightmare
Disabling compression is a good first step to avoid GZIP in XenServer (which is known to be slow).
In any case Gzip is extrremly slow but give a good compress ratio. I already told XAPI guys to give a flag to use LZ4, which is much faster but a little bit less efficient on the compress ratio side.
Anyway, disable it and redo a test.
But you need to define a default SR on any pool you got. Eg: xe pool-param-set uuid=<pool-uuid> default-SR=<sr-uuid> (with the SR UUID of the local storage if you don't have a shared storage).
You can also do it with XenCenter or XO (see https://xen-orchestra.com/blog/set-the-xenserver-default-sr/ )
A live migration won't interrupt the VM, so even with XO on it: doesn't matter.