Xen Orchestra Upgrading

DustinB3403

So... are you running systems that you would only ever consider doing a full system restore of on XenServer?

I'm really looking more importantly at restoring individual files more often than whole systems.

Sure I can use Windows built in Shadow Protect, but that's no good for a whole volume. If I have a network share get encrypted through a workstation by crypto locker, I don't want to restore the whole VM. The server itself isn't infected, the client was. I just want to restore the data for the share.

Currently, today. Yes all of the systems I have in place on XS would I do a full restore on. Also because on my XS VM's don't have any sort of File Level backup solution for these VM's.

Also the VM's aren't that large (that I'm running today).

In production I'm looking at a full 8TB of data, obviously a file level restore solution would be required. But also having the option to restore an delta from the production file servers is a plus. As another backup to Shadow Protect.

Dashrender

Shadow protect isn't a backup. It's a convenience.
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.

Dustin - what is your 8 TB of data?

scottalanmiller

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

DustinB3403

@Dashrender video & audio files and MS office documents are the bulk.

Shadow Protect can restore to bare metal to be a backup solution. But it's not the most graceful (it was there before I was so I'm not fighting that one)

scottalanmiller

@Dashrender said:

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.