Forum ©XSIBackup: ©VMWare ©ESXi Backup Software
MenuYou are not logged in.
- Topics: Active | Unanswered
#901 Re: General matters » Explanation of parameter --exec is missing in man page » 2020-03-04 10:18:39
It's a way to force remote execution which was deprecated but is still present in some older posts. You don't need to use it unless explicitly stated by support.
#902 Re: General matters » error: XSIDiff error, details: rekeyed outbound cipher » 2020-03-04 10:17:01
Well, given the fact that we launched a fix, it'd be difficult to achieve the fix by chance.
Yes, of course we know: the OpenSSH binary has become extremely verbose in latest versions printing to STDOUT irrelevant information such as rekeying, FIPS mode on, etc.... We don't know why OpenSSH development responsibles have decided to do so or whether it is some unintentional pseudobug or some wicked approach.
We have fixed it by intercepting irrelevant information in the SSH tunnel and ignoring it. Messages to be ignored are kept in the [b]conf/err-imsgs[/b] file.
#903 Re: General matters » error: XSIDiff error, details: rekeyed outbound cipher » 2020-02-28 19:30:01
Update to latest version 11.2.19, that will help the issue.
#904 Re: General matters » Upgrade and uninstall procedure » 2020-02-26 18:39:22
Upgrading is easy, just overwrite the installation folder contents, typically [b]/scratch/XSI/XSIBackup-DC[/b].
As the distributable package does not contain any RSA key nor the /etc/jobs folder, you will be safe in regards to overwriting keys or jobs. Nonetheless the /etc folder does contain an [b]/etc/smtpsrvs.conf[/b] file, thus you could simply rename this file in the unzipped upgrade etc folder to keep your eventually preexisting one. We will rename it to [b]/etc/smtpsrvs.conf.sam[/b] in next release so that the upgrade operation is totally safe to perform this way without overwrtting preexisting configurations.
In regards to the uninstall procedure, it is exactly the same as for [b]©XSIBackup-Free & Pro[/b]
1 - Remove the install folder
2 - Make the /var/spool/cron/crontabs/root file editable by root.
3 - Remove the cron schedules
4 - Restore the default permissions on the file
5 - Remove the cron initialization from the [b]/var/spool/cron/crontabs/root[/b] in case you have installed the [b]©XSIBackup[/b] cron
That's all. You can write that logic into this code snippet. Of course change your INSTALLDIR variable value by your own.
INSTALLDIR="/scratch/XSI/XSIBackup-DC"; \
rm -rf "$INSTALLDIR"; \
chmod 0700 /var/spool/cron/crontabs/root; \
sed -i '/-etc\/jobs/d' /var/spool/cron/crontabs/root; \
chmod 0600 /var/spool/cron/crontabs/root; \
sed -i '/update-cron/d' /var/spool/cron/crontabs/root#905 Re: © XSITools » Where are computed hashes? » 2020-02-26 18:20:17
In a remote backup scheme, namely "over IP backups" hashes are computed in the originating host, of course, otherwise we would be adding the uncertainty of whether the block was transmited right, the same happens in a local backup.
When you perform backups over IP (Onediff, Rsync or XSIDiff) and you add [b]--certify-backup=yes[/b], the load to compare the hashes is shared, thus the certification is twice as fast as when you perform the same backup locally.
Lowering the block size will not improve hashing speed, on the contrary, you will have to add the CPU cycles needed to slice extra chunks. In any case the hashing speed is faster than read speed, even with SSDs. This is due to OpenSSH using the [b][url=https://software.intel.com/en-us/articles/intel-sha-extensions]©Intel SHA extensions[/url][/b] which most CPUs incorporate nowadays, thus hashing speed is not among the main concerns when trying to improve backup speed.
[b][https://33hops.com/xsibackup-vmware-esxi-backup.html]©XSIBackup-DC[/url][/b] is certainly your best bet to improve backup speed as it performs most operations in RAM, in any case if your bottleneck is your hardware, there won't be much you'll be able to do.
#906 Re: © OneDiff » XSIDIFF Reports errors after succesful tranfer. Error file transfer er » 2020-02-21 18:36:20
Thank you so much!, we are usually a lot more responsive, we feel a bit guilty about this bug not being fixed before.
#907 Re: (c)XSIBackup-Pro & Free Classic bug tracker » False positive errors » 2020-02-21 11:07:59
We have fixed this issue today. All users of [b](c)XSIBackup-Pro 11.2.17[/b] should upgrade to version [b]11.2.18[/b].
You may also just overwrite the: functions, onediff and version files inside the src folder to upgrade from 11.2.17 to 11.2.18
#908 (c)XSIBackup-Pro & Free Classic bug tracker » False positive errors » 2020-02-20 20:02:07
- admin
- Replies: 1
Due to OpenSSH becoming increasingly verbose about events that shouldn't be probably thrown through the SSH tunnel so happily and a defectuous attempt from our part to capture and discard those errors/warnings, latest (c)XSIBackup-Pro version [b]11.2.17[/b] is throwing empty errors, namely: false positives, with the e-mail report and general output.
We will fix this bug ASAP and will publish it as [b](c)XSIBackup-Pro 11.2.18[/b]
Thank you for your understanding.
#909 Re: © OneDiff » XSIDIFF Reports errors after succesful tranfer. Error file transfer er » 2020-02-20 15:53:32
You are right, those are false positives. Somehow the SSH tunnel is loggin line breaks to the error file, we'll fix that quickly. We believe tomorrow the latest there will be a new version including a fix.
#910 Re: General matters » XSIBackup 11.2.8 - where is jobs directory? » 2020-02-18 10:50:31
Maybe valid weekdays are 0-6
#911 (c)XSIBackup-Pro & Free Classic bug tracker » (c)XSIBackup-DC performance due to job temp files location » 2020-02-16 18:20:55
- admin
- Replies: 0
This isn't really a bug, it is worth mentioning here though. We moved all temporary files to the installation root folder some time ago. This is convenient, as it ensures that enough spece will be allocated to host these files, even for huge VMs. Nonetheless there exists a drawback that we can't ignore and it is that global performance dropped as a result of that.
If you installed [b](c)XSIBackup-DC[/b] to an SSD or you backup over a WAN you won't notice this so much, but people installing to a [b]HD[/b] and moving data in a LAN or between local datastores will notice a severe drop in performance.
We will address this in next main release so that performance of DC returns to be what it was in previous releases.
#912 Re: © XSITools » IP Backup to Synology - error: SHA1 chunk hashes check failed » 2020-02-12 12:40:58
Create a new disk and copy the data to the new one and see if that helps the issue.
#913 Re: General matters » XSIBackup 11.2.8 - where is jobs directory? » 2020-02-06 19:32:21
Please pay attention to the install log:
-----------------------------------------------------
XSIBackup will be installed to the following directory:
-----------------------------------------------------
Install dir: /vmfs/volumes/datastore1/xsi-dir
-----------------------------------------------------
#914 Speed » Intel SHA-1 extensions » 2020-02-06 11:17:21
- admin
- Replies: 2
As many of you already know, [b](c)XSIBackup[/b] in general: [b]Pro[/b] and [b]DC[/b] makes use of the [b]SHA-1[/b] algorithm to index blocks of data. There are multiple reasons for that: it has excellent dispersion properties, it is available in OpenSSL and it's fast.
[b]SHA-1[/b] was conceived for encryption, not just for uniqueness, like: Murmur or Cityhash, thus we are playing an extra CPU cost for a feature that [b](c)XSIBackup[/b] does not need. That is true, but there is an extra fact that is quite important in the equation.
Most Intel processors that are used in servers nowadays incorporate [b][url=https://software.intel.com/en-us/articles/intel-sha-extensions]native ASM extensions[/url][/b] for the SHA-1 algorithm and OpenSSL takes advantage of those extensions, making SHA-1 be extremely fast when it comes to hash data.
#915 Speed » Clogged servers » 2020-02-06 10:17:28
- admin
- Replies: 0
Some people write to us with really low speed figures in the range of 15-30 MB/s, or even lower, on servers from which you should expect much more and connected via decent NICs and switches to peripheral devices.
We have found that in many cases, those poor figures are related to overloaded servers.
Virtualization allows to set up tenths or even hundreds of VMs per server, but that gives many people the wrong idea that you can stretch that forever. Virtual machines make use of the underlying hardware anyways. If you have ten active VMs in a production server, you are short of RAM because of that and [b](c)XSIBackup-DC[/b] has to "beg" CPU time and bandwidth to the system, you can't expect things to run fast.
Size your server in an appropiate way, always leaving some free resources, otherwise you will be just pushing some new stuff into the room for some other to be pushed outside and scratching your head wondering what went wrong.
#916 Re: © XSITools » IP Backup to Synology - error: SHA1 chunk hashes check failed » 2020-02-06 09:58:27
Then you can say that device is not working as expected. Read errors are probably more common on rotational devices (I really don't have any figures on mind now), but when you get some checksum right out of 5, you can say that device is broken without any further comparison.
It might be just a bad cable, some bad disk or something that can be easily fixed, but so many errors indicate a failing device. Keep an eye on the inner cables if any, sometimes you are in a hurry and you just plug whatever you can find in. If some cable is below the spec, things will still work, but you would experience things like that.
#917 Re: © XSITools » IP Backup to Synology - error: SHA1 chunk hashes check failed » 2020-02-05 19:42:57
If you share some output, be it the full log, contact support not to risk sharing sensitive information. The error [b]CLNCERT0[/b] is quite narrowed down. As you are backing up to a local datastore, the problem is even simpler, as both checksums are calculated by the very same OpenSSL binary.
We bet your [b]-flat.vmdk[/b] files are OK, you probably already tried them out.
Could be due to read errors, maybe some bad cable, some faulty memory module. The puzzling part is that they sometimes match, which almost excludes some software issue.
The bad side of certifying things via checksum is that while you don't you remain happily blind, while when you do, you get to the really nitty gritty basement of how things work. If error correction wasn't there computers wouldn't even work.
#918 Re: General matters » XSIBackup 11.2.8 - where is jobs directory? » 2020-02-05 18:10:26
You have an install file in the root of the package. Please, read the [b]README.txt[/b] file. There you can find the information you need to install:
USING THE INSTALLER
Unzip the distribution package in any folder of your ESXi server. You
can then install the package by using the install script, you just need
to make it ("install" file) executable and follow the instructions
on-screen. You can run the below command from the same folder once
you have unpacked the distribution package. If you are reading this,
you have already done so.
# chmod 0700 install && ./install
The install script saves the working /conf folder to a temporary dir
at the /tmp FS and restores it when the install script has finished.
Should you have some RSA or XSIDiff keys, xsibackup-cron.log files,
crontabs, etc... the installation process will respect them.#919 Re: Feature requests & improvements » Replica VS Backup differences » 2020-02-05 18:05:15
Yes, you are right,it's as simple as that.
One of the most recommendable ways of working with [b](c)XSIBackup-DC[/b], although each master has his small book of secrets, is to replicate a VM to a pasive cluster server and then backup the replica, that way you will have a ready to use VM and on addition you will enjoy the benefit of having multiple restore point for each VM.
We will start to add more documentation case studies and resources as we get to a bug free end of branch 1.1.0.0
#920 Re: General matters » Backup on remote server (eSXI) » 2020-02-05 18:00:09
Well, the message is straight concise and short
OpenSSH server at XX.XX.XX.XX:22 can't be reached, timed outAre you able to SSH from host A to B?
ssh root@XX.XX.XX.XX "Echo 'Hello from Host B'"#921 Re: General matters » How to check back-up command state or success » 2020-02-05 00:38:29
Your VMs are rather small, backup should be quite fast. Please, simplify your backup, try to backup the VM that you believe to stop the backup. Run the command on screen and post the output, we are just treating the matter on assumptions. Post the output and we'll have a clearer idea of what's going on. Nonetheless the facts you are describing point at some abnormal behaviour.
#922 Re: © XSITools » IP Backup to Synology - error: SHA1 chunk hashes check failed » 2020-02-03 19:39:31
If you connect your [b]©Synology NAS[/b] via NFS or iSCSI, your remote FS is locally available to the ESXi server and backups are a mere local copy. Nonetheless, the fact that you are mounting over a network and via an intermediary protocol makes the setup more complex and thus more prone to errors, just because it comprises more elements than a plain local disk attached to a local controller.
Nevertheless, if everything is working fine you should expect backups to be made normally.
When you start to receive checksum mismatches, that is a sign that something is not working quite well. In case of locally attached disks, you could infere that some physical damage is causing the errors, you should then run some extensive SMART disgnostics to decide whether some of your HDs or SSDs needs to be replaced.
[url=https://33hops.com/xsibackup-disk-checksum-verification-silent-corruption.html]Checksum verification and silent corruption[/url]
When it comes to NFS and iSCSI, the problem can as well be caused by a faulty disk, but it can also be due to some of the other elements playing a role in remotely mounting the storage volume, such as: cables, switches, NICs, etc...
#923 Re: General matters » xsibackup is trying to backup every folder in the same dir as *.vmdk » 2020-02-03 18:57:00
We aren't quite sure of being fully getting what you are trying to explain.
Do you mean that one of the disks in the VM you are trying to backup resides in the folder where you are actually backing up?
To backup VMs you should use this syntax to select the VMs: [b]"VMs(VM1,VM2,VM3)"[/b]
Please contact support with all the details: backup job, .vmx file content and output.
#924 Re: General matters » How to check back-up command state or success » 2020-02-03 18:48:35
[b]--test-mode=true[/b] in (c)XSIBackup-Free just allows to test the e-mail sending feature and also the selection of VMs nothing else.
If your backup job is not collecting the same number of VMs by using [b]"VMs(RUNNING)"[/b] that can only be due to two circumstances:
1 - The VMs were not there. Are you using [b][url=https://www.vmware.com/es/products/vsphere/drs-dpm.html]DRS[/url][/b]?. Turn off DRS during the backup windows or use the [b]--disable-vmotion[/b] argument.
2 - The VMs were not running. You may cherry pick the ones you want to backup by using the syntax: "VMs(VM1,VM2,VM3)"
#925 Re: General matters » Reports sucess after failed transfer » 2020-02-03 18:42:57
Opss!, sorry we messed up.
(c)XSIDiff uses a syncronous loop, it depends on a reliable TCP/IP stack, it's not good over unstable connections. In any case the fact that you see less used space in the target -flat.vmdk does not necessarily mean that you lost data, as XSIDiff is zero aware, it can punch some zeros and produce a sparse disk which contains less data than the original but is still an exact copy and even produces the same checksum result.
Contact support to provide as much details as possible on this issue and use Rsync instead if you are copying data over some network that you can't trust.