Xen Orchestra Upgrading
-
@scottalanmiller said:
@Dashrender said:
Shadow protect isn't a backup. It's a convenience.
What do you mean? It's absolutely a backup.
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.
-
@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?
-
@Dashrender I actually recommended that in a PM to @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.
-
@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.
-
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.
-
@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?
-
@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-webandxo-serverfolder and do agit checkout stable. Then, you need to rebuild withnpm iandnpm run build. -
@olivier Thanks! Now I just need to write a script and setup a cron job for automatic updates
-
@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.
-
@anonymous I won't do that. Upgrade only when needed. If we change something in the DB structure, or if there is a
npmdependency problem, you Cron job could be dangerous. -
@olivier Thanks!
-
@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
npmdependency 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.
-
@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 alsonpm 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.
-
@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 alsonpm 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.
-
Yes, random stuff is catching NodeBB quite often, although it has gotten loads better.
-
@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.
-
@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 idoes with various versions. I believe that you can manually pull specific versions fornpmbut that is all something I only tinkered with to date. -
Yes, NPM can definitely be controlled.
-
We don't want to stick manually on version for each dependency (there is a lot of them). And what about dependencies of dependencies? That's a HUGE thing to manage manually.
