Xen Orchestra Upgrading

scottalanmiller

I suppose one could decide that it's good enough, and if what you need doesn't fit in that solution, then you do a full recovery. But I guess I just don't see that being the more common desire.

Shadow Protect does full restores. Even bare metal to dissimilar hardware. It's an enterprise class, agent-based, block storage backup system.

Dashrender

@scottalanmiller said:

@Dashrender said:

Shadow protect isn't a backup. It's a convenience.

What do you mean? It's absolutely a backup.

http://www.shadowprotect.com/

I'm using the wrong term - I meant Shadow Copy (build into Windows). I thought Dustin was talking about that.

If he's talking about Shadow Protect from StorageCraft, then yes, of course it's a full backup solution.

Dashrender

@olivier said:

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

If it's not clear enough, come back here

Great post. I do understand what you're doing now.

Are their plans to allow you to have more granular backups? example, every hour for 48 hours, then one per day for 14 days, then once a month for 12 months?
This would result in 74 difference files and the base backup file for this example.

Can merges be done in the vhd's?

DustinB3403

@Dashrender I actually recommended that in a PM to @olivier

olivier

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

Dashrender

@olivier said:

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

Yes - Veeam and other backup vendors have this feature. I mention for example of how they do it.

olivier

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.

Alex Sage

@DustinB3403 @olivier do these commands bring me to the latest stable build, or the latest beta build? I want to upgrade to the latest stable build. What folder do I run the command it or does it not matter? Do I have to run them in both folders?

olivier

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

Alex Sage

@olivier Thanks! Now I just need to write a script and setup a cron job for automatic updates

DustinB3403

@anonymous said:

@olivier Thanks! Now I just need to write a script and setup a cron job for automatic updates

Do share it when you have it built so we can vet it for you.

olivier

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

Alex Sage

@olivier Thanks!

JaredBusch

@olivier said:

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

I completely disagree. That is the entire point of a stable branch. If it is not stable, then remove the name.

olivier

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

JaredBusch

@olivier said:

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

Ok, that is more clear then. Your problem is other packages break your stuff.

This is the same problem I have with NodeBB.

scottalanmiller

Yes, random stuff is catching NodeBB quite often, although it has gotten loads better.

olivier

@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

@olivier said:

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

The solution in my mind is then to have some method of controlling what npm i does with various versions. I believe that you can manually pull specific versions for npm but that is all something I only tinkered with to date.

scottalanmiller

Yes, NPM can definitely be controlled.