BRRABill's Field Report With XenServer
-
Why not make a manual run? (the "play" button) without enabling the job.
-
@olivier said in BRRABill's Field Report With XenServer:
Why not make a manual run? (the "play" button) without enabling the job.
That is what I am doing. But I have to make a schedule. I guess I am saying ... is there a way to just totally skip the scheduling part?
I am sure I am just missing it.
-
Oh ok. No that's good, whatever schedule, not enabling the job and that's it
-
@olivier said in BRRABill's Field Report With XenServer:
Oh ok. No that's good, whatever schedule, not enabling the job and that's it
Yeah that's what I was doing. Thanks!
BTW: is there a typo in the month box? Or do you already know that?
Is ther e a way to search for known bugs so I do not keep telling you the same ones!?!?!
-
@BRRABill Everything should be reported there: https://github.com/vatesfr/xo-web/issues
Feel free to report!
-
@olivier said in BRRABill's Field Report With XenServer:
@BRRABill Everything should be reported there: https://github.com/vatesfr/xo-web/issues
Feel free to report!
Done.
My first ever.
You never forget your first!
-
Another thing I noticed...not sure if this is a bug or something that is supposed to be...
If you go back into a backup job without compression to edit it, the "USE COMPRESSION" switch is set to on.
Is that a bug? If so I will add that as well.
-
Report any issue
-
@olivier said in BRRABill's Field Report With XenServer:
Report any issue
My new nickname will be ... the phantom menace.
-
Last one for the day!
Can you explain what these log items on the backup mean? I think I may have found a bug there, too.
vm.rollingBackup: tag: test with compression _reportWhen: never depth: 2 remoteId: remote-10 onlyMetadata: compress: VM: XenOrchestra (xenserver-MAIN) true
-
Basic backup with tag "test", compression enabled, never report any failure or success by email, retention of 2. Saving on "remote10". All of this on vm XO hosted on xenserver-MAIN.
-
@olivier said in BRRABill's Field Report With XenServer:
Basic backup with tag "test", compression enabled, never report any failure or success by email, retention of 2. Saving on "remote10". All of this on vm XO hosted on xenserver-MAIN.
How did you know compression was enabled?
-
@BRRABill said in BRRABill's Field Report With XenServer:
@olivier said in BRRABill's Field Report With XenServer:
Basic backup with tag "test", compression enabled, never report any failure or success by email, retention of 2. Saving on "remote10". All of this on vm XO hosted on xenserver-MAIN.
How did you know compression was enabled?
Just guessing that "with compression"
-
@travisdh1 said in BRRABill's Field Report With XenServer:
@BRRABill said in BRRABill's Field Report With XenServer:
@olivier said in BRRABill's Field Report With XenServer:
Basic backup with tag "test", compression enabled, never report any failure or success by email, retention of 2. Saving on "remote10". All of this on vm XO hosted on xenserver-MAIN.
How did you know compression was enabled?
Just guessing that "with compression"
That was the name of my job.
"test with compression"
-
@BRRABill said in BRRABill's Field Report With XenServer:
@travisdh1 said in BRRABill's Field Report With XenServer:
@BRRABill said in BRRABill's Field Report With XenServer:
@olivier said in BRRABill's Field Report With XenServer:
Basic backup with tag "test", compression enabled, never report any failure or success by email, retention of 2. Saving on "remote10". All of this on vm XO hosted on xenserver-MAIN.
How did you know compression was enabled?
Just guessing that "with compression"
That was the name of my job.
"test with compression"
Ah, 2nd guess, compress:
-
@travisdh1 said
Ah, 2nd guess, compress:
Both the jobs with and without compression both say "compress:"
I'm wondering if it was supposed to say
"compress:yes"
or something.Which is why I am wondering if it is a bug.
-
Sounds likely that something is wrong there.
-
@scottalanmiller said in BRRABill's Field Report With XenServer:
Sounds likely that something is wrong there.
I can't tell if I am reporting things that have already been fixed, or not.
This has nothing to do with me. It's my inexperience with GitHub.
These are the two responses I received.
Closed #1338 via bd70bd2.
Closed #1339 via #1347.Does the top one mean it was a new fix? And the bottom one mean they were aware already?
-
Closed means the issue is "finished": without extra comment or specific tag (like duplicate, invalid or won't fix), it means that's solved.
You can follow links to see what fixed the issue (in the "via #1347" or the commit hash).
TL;DR: issues fixed. Will be released in the "next wagon".
-
@olivier said in BRRABill's Field Report With XenServer:
Closed means the issue is "finished": without extra comment or specific tag (like duplicate, invalid or won't fix), it means that's solved.
You can follow links to see what fixed the issue (in the "via #1347" or the commit hash).
TL;DR: issues fixed. Will be released in the "next wagon".
Right, but I was "afraid" of posting stuff you already knew about.
So "via 1347" means there was already an issue similar, and the fix was the same?
What does the hex link mean?
Thanks for another day of education!
