You are not logged in.
This is a clear bug in the bash interpreter of Busybox. We can provide a solution for those that for some reason cannot skip this ESXi version (6.7 U2), although, as this bug will affect any other bash script, and there are some used by ESXi internally, using this version in production is a kind of shooting your feet.
[b]Workaround:[/b]
[b]1[/b]: copy some older busybox release from an older version of ESXi to your xsi-dir/bin folder in ESXi 6.7 U2. We used busybox in ESXi 6.5, its location is:
/usr/lib/vmware/busybox/bin/busybox[b]2[/b]: create a hardlink in the [b]xsi-dir[/b] named sh and pointing to the busybox binary you just copied.
ln -s /vmfs/volumes/datastore1/xsi-dir/bin/busybox /vmfs/volumes/datastore1/xsi-dir/sh[b]3[/b]: change the shebang at the top of the xsibackup script and point it to the newly created [b]sh[/b] link
#!/vmfs/volumes/datastore1/xsi-dir/shThis is just a quick workaround that we have not tested thoroughly, so use at your own risk. The recommended procedure is to skip this broken ESXi release.
We were just thinking loud, the cause of your problem could be something else. Please allow some days for us to check this issue and point you in the right direction. Restore locally in the meanwhile if you need to .
I'm afraid no config option should control wether a plain ampersand or parenthesis character is parsed by the interpreter when enclosed in double or even single quotes. We have found this to be happening even on commented out lines, thus is seems to be a bug.
That may be the reason. If that was the case we would obviously add some logic to fix it, as the restore process has to work even if the VM is renamed. We are now busy with some ESXi bug in the bash interpreter, so we would hopefully have something ready after Easter holydays.
UPDATE 1:
We have found that VMWare has upgraded Busybox from v 1.22 to 1.29 in their latest minor update ESXi 6.7 U2
The bash interpreter bundled with this Busybox version treats some text inside quotes, even single quotes ;-( as code and tries to parse it through the interpreter instead of escaping it. We have found this to happen with parenthesis and ampersands, but may affect other characters too.
This apparent bug will affect, not only XSIBackup, but any other bash scripts that may be needed by ESXi, including service scripts.
We recommend that you skip this build by now and wait to see if VMWare does something in regards to this issue.
UPDATE 2:
As per our latest tests, it seems to be affecting even commented out text, so we believe this to be a Busybox/ ESXi bug.
This seems to be a problem determining the name of the remote VM. Does it contain some space or special character?
We have confirmed this to be a compatibility issue with ESXi 6.7U2, the problem was already fixed. [url=https://33hops.com/download-form.html]Download latest version[/url]
Some changes in the bash interpreter bundled with ESXi have caused some kind of incompatibility in ESXi 6.7U2. We'll fix this issue in short so that XSIBACKUP-PRO is compatible with version 6.7U2
xsibackup: line 605: syntax error: unexpected "&"This error is due to some changes in the keep alive policy of the SSH server in the sshd_config file. You can easily tweak that to prevent these errors by increasing the keep alive interval. We might include this adjustments to be performed by XSIBACKUP-PRO in some future version, although being something affecting your security profile, we'll leave it to the sysadmin by now.
Each new (c)ESXI version comes with a new version of OpenSSH and with a different configuration. That error is thrown because of the SSHD keep alive configuration. The transfer finishes O.K. cause that's an ongoing communication but the rest of the tunnel times out.
Just tweak your keep alive configuration in your sshd_config file:
[url=https://www.digitalocean.com/community/questions/why-am-i-getting-packet_write_wait-connection-to-xxx-xx-xx-xxx-port-22-broken-pipe]Tweak keep alive values in OpenSSH[/url]
We published that bug, but then discussed about the convenience of auto tweaking something as critical as the sshd_config file, that should be left to the sysadmin.
And you are backing up from which version?
Please post all the relevant facts.
XSITools is a deduplication engine. Please, read before using, it stores data in deduplicated chunks, what you see is not what you probably think you are seeing. Those folders do not contain data, but hashmaps, those folders can't be deleted without pruning the deduplicated repository. On top of that (c)XSITools is a trial feature in XSIBackup-Free, so you won't be able to restore or prune those backups unless you buy the Pro version.
If you want to keep using Free, use --backup-prog=Vmkfstools|Rsync|Onediff
[url=https://33hops.com/xsitools-vmfs-deduplication.html]Deduplicate on VMFS with (c)XSITools[/url]
[url=https://33hops.com/xsibackup-using-backup-programs.html](c)XSIBackup Classic: using backup programs[/url]
We are sorry, but this is probably not the most adequate site to place questions about setting the time of your ESXi server
O.K., just to eliminate the most obvious probable reason.
Is you backend a Linux server or an ESXi server?
You don't need Pro if you have a nice bandwidth through the VPN and you trust your backups without any further checksum certification. Just use the datastore as you would do with any other local storage resource. Enable async NFS to improve transfer speed.
Only folders looking like this will be considered when calculating the amount of space used
[b]20190410013022[/b]
[url=https://communities.vmware.com/thread/596950]Configure Time Zone in (c)ESXi[/url]
This is not an XSIBackup issue. You are receiving a communications error:
packet_write_wait: Connection to 87.139.234.106 port 5006: Broken pipeBroken pipe, no connection. Is the server reachable at port 5006?
Remove the comments from the job file and leave the commands starting with this line:
"/vmfs/volumes/backup/xsi-dir/xsibackup" \Only folders pledging to the datedirmask variable in the conf/xsiopts file are considered for deletion.
datedirmask=20[1-3][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]We aren't trying to be unpolite, but just clear. XSIBackup is not a closed featured piece of software. As stated before, it may produce any result, depending on the user actions.
We have thoroughly tested that switch and we have not been able to reproduce your issue so far. Nobody else has reported such bug either among many thousands of users.
That leads us to believe your outcome is due to some particular condition in your system. Remember that XSIBackup does not support manufacturer builds.
When you hit some particular problem, just contact support directly. You can find all details in the welcome e-mail. Or just send us a [https://33hops.com/contact-form.html]contact form[/url]
We may some day dedicate a post to REGEXP patterns, but by now, it's a general purpose tecnology which is well stablished and well documented in a multitude of websites, i.e.:
[url=https://www.digitalocean.com/community/tutorials/using-grep-regular-expressions-to-search-for-text-patterns-in-linux]Rgexp tutorial[/url]
(c)XSITools is a deduplication engine:
[url=https://33hops.com/xsitools-vmfs-deduplication.html](c)XSIBackup Classic: deduplicate on top of VMFS[/url]
No, it's not a regular backup.
You are the sysadmin of your system, you may debug to find out why that is happening or ask somebody else to do it for you.
XSIBackup is extremely flexible, as some functionality is based in scripts, you may very well do something that produces any result.
We can debug that for you, but if it turns out to be some error from your part, we will charge for our time.