@JaredBusch That's a common problem is software development ^^ That's why Linux distributions exists: gathering a lot of small programs and making them working together.

@JaredBusch You don't get it. It's not about the XO code itself, it's all about dependencies.

Eg. by making a CRON job which git pull (no problem) everyday but also npm i: that's the issue. If a related dependency changed, and even XO doesn't, you could break the software. We saw the issue recently with lodash team making a big mistake which affected a LOT of projects using it.

edit: again, that's the point of XOA: packing something with QA on the software but also on dependencies. You can imagine this like a distro.

@anonymous I won't do that. Upgrade only when needed. If we change something in the DB structure, or if there is a npm dependency problem, you Cron job could be dangerous.

@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.

Currently uploading new XOA's, but:

• code is already merged in stable
• existing XOAs can already upgrade!

Hmm.. Even in forever forward incremental?

edit: because we merge offline, the full disk will be modified accordingly. It will be correct for a "subjob", e.g every hour. But the base won't be anymore correct for another "subjob", let's say every day: because it's now modified by the other one.

edit: or they need to be synchronized (at the same time). Let's say every hour at the hour (3:00, 4:00) and another one every day, at 3:00. This way we could roll fully offline, by having a copy of the delta preserved for a longer time.

@Dashrender You mean without creating multiple backup jobs? (to avoid full disks multiplications?)

edit: final merge (ie during the import for restore purpose) is done inside XAPI and not offline.

The question is: is it possible to manage multiple/various backup time and retention by keeping only one full disk.

Totally ^^

Exactly, you can't do file-level backup without an agent installed on your VM!

So you'll have 24 files per VM disk: 1 full vhd and 23 delta. Each new backup will:

• create a new delta vhd file
• merge the oldest delta vhd in the full
• remove this oldest delta

You will be able to restore any of those 24 last backup.

Go read the blog post: https://xen-orchestra.com/blog/continuous-delta-backup/

If it's not clear enough, come back here

@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.

@Dashrender said:

@DustinB3403 said:

If I take hourly delta backups, I want to go back 3 hours and restore from there, not be limited only to the most recent backup.

it's just a feature I want.

This is exactly how it works

Remember:

Then:

@DustinB3403 only the oldest delta!

@DustinB3403 Please display the content of the vdi folder, that's where it's interesting

@JaredBusch I'm curious, how much time to be considered as "been around"? You mean maybe more market adoption?

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).

Please keep in mind we are talking here about someone:

• being on the beta branch to test a feature before the official release
• on a source install
• without the updater inside XOA
• without pro support

If you got the appliance, nothing to do. Just click on "upgrade" when it's out. So it can compete, but yes, it's not free

edit: I have no problem to be compared in terms of pricing even between VEAAM and XOA.

edit2: being turnkey is the base of our business model

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"