Forum ©XSIBackup: ©VMWare ©ESXi Backup Software
MenuYou are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 General matters » Bad changelog » 2020-06-12 21:04:37
- Timbo
- Replies: 1
Changelog has 11.2.9 as both the latest version and a previous release with different change notes for each entry.
I'd have assumed it was a typo and maybe you meant 11.2.29, but 11.2.19 is still was is available to install/download when logged in, so I don't even know the correct version.
#2 Re: General matters » No daily backups after a power outage » 2019-02-15 23:50:26
Your problem is a lot easier to understand that having to go through all the checks in this post. The clue to resolving your problem and using our software appropiately is that you are overlooking some fundamental pieces of information, even though it's clear that the program's output and this very same post thread are insisting on them:
1 - The ESXi crontab is not persistent.
2 - Our software adds that line to the /etc/rc.local.d/local.sh when you install the XSIBackup cron to make sure the XSIBackup crontab contents are re-copied to the ESXi's crontab on every reboot.
3 - The message: 2019-02-05T14:30:06| Alert: crontab is not installed for user root is almost desperately letting you know that point.So, yes, you are right. Your backups would have never resumed on reboot, even if no power outage event would have occured.
No software can be "resilient and robust" when you have not installed it.
Here's the crux of the issue. I'm (edit: was) arguing I *DID* install cron. And I thought that was confirmed with daily backups occurring. But its looking like I didn't, but I'm still able to configure jobs that run using cron. I just went in and viewed the job and changed a few screens but didn't make any changes. Very briefly, it tells me the root crontab has been updated.
Let's say you install on a fresh system. You configure a job. If the user doesn't explicitly install cron service, the expectation is that the jobs will fire according to schedule until rebooted, just not after a reboot, and that's what happened here. I know that's not my use case, maybe someone else will, but can't think of it right now.
Yep, I will have to say, it is looking like I didn't install cron. I just went to this screen and its telling me to "Enter the crontab username" (not 'select'), but doesn't have a place to enter a username. It displays "root" and "Administrator", with only the "r" in root in black and the whole "Administrator" in black, so it looks like Administrator is selected. Up/down arrows don't work, tab just selects between OK and Cancel. Pressing "r" does not change anything. So I can say now with confidence, I did not install cron service because I would have had feedback on this screen for sure. It needs work. Edit: I think I understand now. There is only *one* user, "root", who has the role of "Administrator", not two users, "root" and "Administrator". So if there were multiple users, then pressing "r" would have selected root. I can see this making more sense if there were more users to select. It would be an optimization to JUST automatically select the root user when only the root user is displayed.
I would prefer the installer automatically (or prompt to install it by default) install cron service during initial installation and not make the user manually install it. Saves a step and will make a better default setting.
So, my feedback:
1. Install cron setting on boot service by default during install, or prompt user with default option to install it
2. In the GUI, on the Cron Install/Remove screen, show the current cron installation status
3. Expose the "Alert: crontab is not installed for user root" to the emailed results
4. Users are idiots. The more you can do to help them not make mistakes, the better the software looks.
Thanks and have a great weekend.
p.s. Please increase the forum login timeout. I'll be logged in when starting a reply, and logged out by the time I go to submit the post. Luckily, browser back still has the post contents to paste back in after relogin.
#3 Re: General matters » No daily backups after a power outage » 2019-02-15 00:35:51
We really don't know what's the point in your argument.
So, you always used backup software that sent notifications when it was not working?.
Your issue is most probably related to your cron service, so we find it a bit difficult that any e-mails could be sent.By the way, the crond service is ESxi's cron, but there isn't any reason why it shouldn't work, unless something wen't wrong in the reboot.
Inspect the /etc/rc.local.d/local.sh file, it should look like this.
If it does not, maybe it's due to the crontab having been edited manually and your changes having been lost in the reboot.#!/bin/sh # local configuration options # Note: modify at your own risk! If you do/use anything in this # script that is not part of a stable API (relying on files to be in # specific places, specific tools, specific output, etc) there is a # possibility you will end up with a broken system after patching or # upgrading. Changes are not supported unless under direction of # VMware support. # Note: This script will not be run when UEFI secure boot is enabled. "/vmfs/volumes/datastore1/xsibackup-dir/src/cron-init" root exit 0
I said exactly my point, "Backups need to be resilient and robust.". Yes, of course, I expect emails when ***backups*** fail. I've always received emails for failed backups because there was a problem with the VM or destinations, not in the programs launching themselves. I've never had a problem with backup software failing to start their services on boot (edit, this isn't true. Crashplan will from time to time fail to start on boot, where they usually fix it with a software upgrade. In these cases, an email is sent from their cloud because no backups occurred in X days. But I would argue that is a consumer managed desktop, not a headless ESXi Server), with many more power failures than the first and only one I ran into before having a problem. If a program's service fails to start on Windows or Linux consistently, I'd switch to another app.
I've used remote access software on headless and hard to reach servers for decades. They need to always restart itself, reconnect, retry broken connections over and over, etc. It should perform error checks and correct if something will prevent it from working. Everything it can and should do to ensure the remote access is always available and prevent a truck roll or onsite visit. My first suggestion, was something that indicates the cron installation status, as the GUI shows to install or remove, nothing to indicate whether its currently enabled/installed.
So, getting back to troubleshooting.
No, /etc/rc.local.d/local.sh doesn't contain that line. Blank space where that line is.
No, /var/spool/cron/crontabs/root doesn't contain the xsibackup line to backup job 1.
#min hour day mon dow command
1 1 * * * /sbin/tmpwatch.py
1 * * * * /sbin/auto-backup.sh
0 * * * * /usr/lib/vmware/vmksummary/log-heartbeat.py
*/5 * * * * /bin/hostd-probe.sh ++group=host/vim/vmvisor/hostd-probe/stats/sh
00 1 * * * localcli storage core device purgecat conf/root-crontab
30 14 * * * "/vmfs/volumes/59a3eb97-be17a947-81b7-0cc47a47ea53/xsi-dir/jobs/1"One thing I noticed when running the job manually, is the line:
cat xsibackup.log |grep crontab
2019-01-21T23:12:14| Alert: crontab is not installed for user root
2019-01-22T10:50:20| Alert: crontab is not installed for user root
2019-01-22T11:06:39| Alert: crontab is not installed for user root
2019-01-22T14:30:08| Alert: crontab is not installed for user root
2019-01-23T03:15:40| Alert: crontab is not installed for user root
2019-01-23T14:30:06| Alert: crontab is not installed for user root
2019-01-24T14:30:07| Alert: crontab is not installed for user root
2019-01-25T14:30:07| Alert: crontab is not installed for user root
2019-01-26T14:30:07| Alert: crontab is not installed for user root
2019-01-27T14:30:07| Alert: crontab is not installed for user root
2019-01-28T14:30:06| Alert: crontab is not installed for user root
2019-01-29T14:30:06| Alert: crontab is not installed for user root
2019-01-30T14:30:06| Alert: crontab is not installed for user root
2019-01-31T14:30:06| Alert: crontab is not installed for user root
2019-02-01T14:30:06| Alert: crontab is not installed for user root
2019-02-02T14:30:07| Alert: crontab is not installed for user root
2019-02-03T14:30:06| Alert: crontab is not installed for user root
2019-02-04T14:30:06| Alert: crontab is not installed for user root
2019-02-05T14:30:06| Alert: crontab is not installed for user root
2019-02-06T14:30:06| Alert: crontab is not installed for user root
2019-02-07T14:30:06| Alert: crontab is not installed for user root
2019-02-08T14:30:06| Alert: crontab is not installed for user root
2019-02-09T14:30:07| Alert: crontab is not installed for user root
2019-02-14T11:27:05| Alert: crontab is not installed for user root
This makes me think if I rebooted the ESXi box before the power failure, the same result would occur.
This appears in the xsibackup.log, but not in the emails. Maybe it should be an ERROR and not an Alert that doesn't get seen by user? Not sure how I'm getting daily job executions if crontab is not installed for user root. But I would suggest including this in the emails so the user knows crontab wasn't installed properly. Otherwise, when the job is running daily, the user THINKS the installation went fine, when it didn't.
I have made no manual mods to cron. I used the provided installer and configured one job through GUI.
In the troubleshooting guide, I'm currently stuck on step 3. I get no error when chmod'ing /var/spool/cron/crontabs/root, but vi gives me an error when trying to save.
'/var/spool/cron/crontabs/root' Operation not permitted
So yea, the xsibackup job isn't being saved to /var/spool/cron/crontabs/root for some permissions issue.
ls -la /var/spool/cron/crontabs/root
-rwx------ 1 root root 324 Sep 29 2017 /var/spool/cron/crontabs/rootp.s. on the troubleshooting page, you suggest to run commands blindly, but you don't say to adjust for the datastore path the xsibackup is installed to, and you incorrectly tell them to tail the conf log file that has since been moved to var/logs/xsibackup.log, not conf/xsibackup.log. It would be better to tell the user to adapt the command than to tell them to run them blindly. Running blindly usually means "copy and paste and don't change".
I just googled the operation not permitted and got an ESXi forum response https://communities.vmware.com/thread/337354. I cp'd root to root2, added the xsibackup line to it, successfully saved it, then mv'd root2 back to root. I can now edit root file without problem. Major *shrug* on that behaviour. But its been observed going back to ESXi 5, at least.
I added the date test to the root cron file, but it wasn't getting written to. So I ran these commands, and now it is working. So not sure if the commands I did in troubleshooting step 2 actually worked.
# kill -HUP $(cat /var/run/crond.pid)
# /usr/lib/vmware/busybox/bin/busybox crondYou can probably add this to step 3 or make a step 4 so people don't go through the hassle of reinstalling ESXi when they don't need to.
When you're copying the root-crontab contents to root, you're checking that it wrote successfully, right? If not, you can try the copy, edit, move plus crond restart to get things working again. That will make it more resilient.
I'll try and find some time this weekend to do a reboot test and see if the cron copy happens successfully this time.
Regards
#4 Re: General matters » No daily backups after a power outage » 2019-02-13 20:33:59
You said:
"On Saturday, we had a power outage midway through one of the backups"
And then
"It's been up 3 days now, and the nightly backups have not resumed. That is a very bad sign for a backup solution"
Haven't you thought of the possibility that the outage caused some additional trouble that you need to fix?, that is not a trivial incident for a server.
- Make sure that your cron service is running and is loaded just once.
- Check that the (c)ESXi crontab is O.K.(c)XSIBackup Classic: troubleshooting the (c)ESXi cron service
That's the point of why I'm here. I can't think of another backup solution I've ever used that didn't resume backups or inform through some notification that backups were no longer happening. So when it doesn't automatically resume backups, something MUST be wrong. On all my linux boxes, I've never had cron stuff just stop getting called.
There are no other known issues with the server. VM's restarted. All storage is accounted for. RAID operation status ok. No errors in ESXi. This is the reason I had an expectation of backups resuming. I'll work on the troubleshooting later today.
#5 General matters » No daily backups after a power outage » 2019-02-12 22:50:15
- Timbo
- Replies: 7
I configured a nightly backup of our VM server and was getting emails each morning with the result for the last week or more.
On Saturday, we had a power outage midway through one of the backups. It only lasted a few hours and power was restored and VM restarted. The xsibackup.log ends on the 9th with the last line cloning at 21%. It's been up 3 days now, and the nightly backups have not resumed. That is a very bad sign for a backup solution. Backups need to be resilient and robust.
When I check the jobs in xsibackup, it still lists the job and shows it enabled.
The options are to install cron or remove cron, it would be good to see the current cron status to see if the problem is cron not being installed (which would imply an installation issue with your install script).
What do I have to do to get backups working again? Reinstall cron?
Thanks
#6 Re: General matters » Emailed report improvements » 2019-02-03 00:09:19
Thank you for your feedback.
1 - Giga bits per second are usually abbreviated as gbps and giga bit as gbit. GiB is a different unit measure: Gibibyte, which stands for Giga Binary Byte => 10 raised to the 30th power. Assuming that a "b" in lower case stands for bit and an upper case one stands for byte is not correct, we will buy that as an styling matter anyway and will disambiguate that in next versions.
2 - You are right, that "yet" is redundant and most probably meaningless, maybe "Off indeed" would have been a better bet, but we are forced to keep texts as short as possible, which is an additional constraint. You are a much better source of knowledge in this matters, so we'll take your advice into account.
3 - In regards to the capitalization of these acronyms. They have become words on their own, thus you will see them capitalized and in lower case too. We'll buy that as an styling issue.
The forward slash means something different inside of the cell, there it separates the real size of the data from the nominal size of the sparse disk. These two figures will be equal in case of thick disks. In case of the MB/s unit marker, it separates the dividend from the divisor.
4 - We'll try to arrange that a bit better, but the type of HTML that e-mail clients are able to interpret is rather limiting.
1. No, virtually never. Lowercase "gbps" just isn't used, nor is "gbit". I've been reading electronic component datasheets all week long, and they consistently used "GBits/MBits" and "GBytes/MBytes" when speaking in size. Go look on any review site for testing storage. They consistently use "MB/s" for talking storage transfer speeds.
It IS very common for "B" to be bytes and "b" to be bits. I'll just mention these two search results: https://www.wu.ece.ufl.edu/links/dataRa … Chart.html and https://kb.iu.edu/d/ackw. The later url says:
Note: The names and abbreviations for numbers of bytes are easily confused with the notations for bits. The abbreviations for numbers of bits use a lower-case "b" instead of an upper-case "B". Since one byte is made up of eight bits, this difference can be significant. For example, if a broadband Internet connection is advertised with a download speed of 3.0 Mbps, its speed is 3.0 megabits per second, or 0.375 megabytes per second (which would be abbreviated as 0.375 MBps). Bits and bit rates (bits over time, as in bits per second [bps]) are most commonly used to describe connection speeds, so pay particular attention when comparing Internet connection providers and services.
3. It is useful to know what speed the data actually transfers at to know whether a hard drive is performing as expected or poorly. I do not see any benefit or usefulness to know what the sparse size of the disk transferred at. Its a nonreal measurement and will vary depending on how much the VM is filled up, nothing to do with performance and no indicator of problem or not. It actually makes it harder to spot problems by putting two numbers into same column. Only the actual data transferred over time is useful. Please remove the sparse calculation and just use the actual data transferred over time.
4. I see your point about the mail client and browser. I viewed it in Thunderbird and didn't look as nicely as when I saved it as html and opened it in a browser. Now I can see the sparse numbers are greyed vs black, so it is easier to differentiate. Maybe at the very bottom of the email, you can say, "Best viewed in browser" or something. I think people will be grateful for viewing it in full html rendering.
What does the "Start" column represent? It's just dashes in my reports.
Edit: Nevermind about the html message. I wanted to figure out why Thunderbird didn't display properly, and it was because it thought the email was junk. When I told it it wasn't, the coloured text appeared. I don't like the remote content from 33hops.com being included (why include advertising banner for an already paid product? Just include it in free version, please. Same for the stupid Twitter, Facebook and linkedin icons/links. It's a STATUS REPORT!!!), that seems to be why it was flagged as spam.
#7 General matters » Emailed report improvements » 2019-01-24 19:50:25
- Timbo
- Replies: 2
After getting email reports working, I was a little confused by the way the report displays the data.
1. Size is listed as "(Gb)", but this should be "(GB)" or "(GiB)". Bytes, not bits.
2. Under the column "Stop", there are entries for "Off yet". "yet" makes no sense. Is that supposed to be "yes"? Also, I would have went with "Stopped" as a past tense event, but that's minor.
3. The speed is listed as "Speed (mb/s)". It doesn't appear that it is "mb/s" and more likely "MB/s". In addition, you represent the data like 88/616, which means you're saying "88mb/616s", which is outright wrong. I'm guessing this is supposed to be a write/read indicator, but its not, its confusing. These numbers vary quite a bit over 11 VM's, so it really isn't useful without knowing what is being displayed.
4. When it prints "The eldest folders were deleted to make room", the next line is blank and then it prints the path that was deleted. It would be better if the blank like was moved to after the path, so the message is together and visually separated from the next VM's being backed up. Just a minor cosmetic improvement to improve readability.
Best regards
#8 Re: General matters » Emails didn't send to my mailboxes. » 2019-01-24 19:34:00
SSL is deprecated, TLS is the new standard for secure communications
So to be clear, in your QA testing of Gmail, you're using TLS and port 587? Because we're reporting these typical settings works elsewhere but NOT for XSIBackup.
#9 Re: General matters » Emails didn't send to my mailboxes. » 2019-01-23 20:33:28
There is indeed an Smtp sec: field in the GUI, please, take a closer look.
The GUI reads "SMTP Security set to TLS (default), change to none if you want unencrypted pwd".
No mention of SSL being an option. But again, the default option of TLS *IS* what most people would select and works for other setups.
#10 Re: General matters » Facing problem with XSIBACKUP 11 on 4 Servers » 2019-01-23 04:28:07
In an older thread https://33hops.com/forum/viewtopic.php?id=20, there were two possibilities raised:
1. The VM isn't registered with ESXi properly (maybe remove and readd it to inventory)
2. The VM was suspended.
The issue was not resolved, but the takeaway is that this is an ESXi error, and XSIbackup just gets told this error by ESXi.
Edit: Google search turned up this thread that has a solution. Take a look: https://communities.vmware.com/thread/398000
#11 Re: General matters » Download Issues » 2019-01-23 01:01:35
Same issue back in June. I had to contact them because it wouldn't work from several locations from several emails. It was clearly an issue on their end.
For the auto script installs, one thing to watch for, is that there are sometimes typo's in the commands you're supposed to copy and paste. Happened when they changed default filename for the zip.
#12 Re: General matters » Emails didn't send to my mailboxes. » 2019-01-23 00:56:07
Glad I found this thread. Was getting pretty frustrated because I had gmail emails sending just fine on the older free version. Since SSL isn't an option in the GUI, then logically you select port 587 because GMAIL supports TLS on port 587, not 465.
Port 465 (SSL required)
Port 587 (TLS required)
Why it works on port 465 (The SSL port) for the TLS setting instead of port 587 (The TLS port) sounds like a bug in the software. In the older command line, it worked when explicitly including "--smtp-sec=SSL" and using port 465. You don't even have an SSL option in the GUI to select.
You'd probably save some customer hassles by just changing your GUI to say its doing SSL and not TLS.
https://support.google.com/a/answer/176600?hl=en. Then people will know to select port 465 and not 587 as per the gmail instructions.
For any other servers I manage, I've only used port 587 and this is the first time running into an issue like this.
Pages: 1