You are not logged in.
It's probably the check for new versions, it has a 1 sec. timeout though
Set the [b]checkver[/b] variable to "no" in [b]conf/xsiopts[/b]
checkver=noThank you, we already fixed it
Please, use [b]--check-repo=yes[/b] instead, we will add an alias as [b]--certify-backup=yes[/b] in next version.
Sorry about the delay, but these days we are less than usual.
You don't need identical ESXi versions, but you do need a coherent environment: uniform VMFS versions and compatible HW versions in every engaged host.
Please, contact support to solve your particular issue, it probably has to do with your metadata information. I don't think the forum is the best place to post files with thousands of lines.
Execute this code snippet and send us the output as an attachment:
vmkfstools -t0 /path/to/your/problematic/disk.vmdk > /tmp/metadata.txtWe'll check this kind of verification and reach you back.
In regards to the certification mistmatches, you are assuming that when the mismatch is due to a read error, the following time that you try to perform the same action, it will succeed. The thing is that even seldom read errors can become really sticky and persists throught many read tries, thus if you automatically repeat the backup for that VM, you may end up with 40 backups until it eventually disappears.
A certification error doesn't require any automatic action, it can be safely ignored when it's seldom and affects new disks or may require manual intervention to change cables or disks. Reapeating a backup on a failed certification will not ensure that the subsequent certification try will succeed and the chances that you enter a loop are extremely high.
A certification error does require you to evaluate the situation. If you believe your disks are a bit worn out, but not as much as to be worried about its health, you can reinstantiate the Onediff cycle or just switch the VM as recommended above to make sure it's O.K.
A Onediff cycle is a backup instance in which the differential Onediff snapshot is copied from the source VM and integrated or coalesced with the previously existing data, resulting in an exact copy of the source VM.
If you switch on a Onediff mirror, you will modify the mirror base disk with some unique data on the mirrored side, when you perform the subsequent Onediff cycle, the resulting Onediff mirror VM will not match the source one.
A plain approach to prevent this situation, given the fact that you need to start the mirror VM for some reason, would be to make a full copy of the mirror and start that new VM.
Fortunately there is a simpler approach: you can just add an snapshot to the mirror VM and switch the VM on, then all new data that is generated for that VM will be stored in the snapshot and all disks below the new snapshot will remain untouched. Once you are done with whatever you needed to do on the mirror VM, you just discard the whole snapshot and the base disks will remain untouched thus allowing the Onediff chain of differential snapshots to continue without any mismatch.
There isn't any issue around that, please inspect the log and contact support in case you need to.
Sorry we didn't state why we haven't created that option, it's mainly due to the sticky character of these situations which may enter a non stop loop in many cases, that makes the option not very practical.
There are some other considerations to take on account, as whether you are using async or sync NFS.
[url=https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-nfs.html]Network File System protocol description and versions[/url]
Try to use high quality cables and consider this checksum errors some "safe to ignore" mistmatches while you are confident about your disks. They will start to show much more often when they wear out.
You can just add a snapshot to your Onediff image and start your VM after one of these episodes. Then get rid of the snapshot and the Onediff cycle will not be interrupted. Some other manufacturers like Nakivo use some more naive verification systems, like a screenshot of the VM, most probably to avoid explaining users that certifying copies may not always show a perfect match cause disks are not perfect devices, so data storage can only be treated from an statistical point of view.
Most of the times checksum mistmatches will be due to read errors, they are very sticky though, so you might keep on getting the same read error on the same block a number of times. Generally this kind of repetitive checksum error on the same sector is safe to ignore. The chances that your backup is O.K. are high, you should nonetheless keep an eye on the backups, especially if your hardware is not new. Always use high quality cables, this will reduce errors.
Read this post for a more complete view on the matter:
[url=https://33hops.com/xsibackup-disk-checksum-verification-silent-corruption.html]Checksum verification what it is and what you should expect from it[/url]
We'll take that as a feature request and add that a a parameter in [b]conf/xsiopts[/b] file in next version.
No you cannot separate jobs by commas, you can't use four digits either, you must use job names 000 - 999
You can't combine scripts with the GUI, some advanced techniques like this will require you to edit the job files manually. It isn't a big deal in any case, just cut and paste jobs one after another or create your own scripts (remember 000-999) and invoke them as if they were jobs.
Backup jobs must be named 000 to 999, you may place any script placed in the jobs folder and call it from --on-success and --on-error.
That differentiation is only made so that you can trigger different things in each case, but if you just want to launch something in any case, then you can just write jobs one after another in the same job file.
You may look for the [b]wait2shut[/b] variable at around line 4009 in the main [b]xsibackup[/b] file and increase its value to your desired limit.
Maybe you are assuming the size has something to do with the issue when it might not. We suspect the metadata layout might be broken or extremely highly fragmented. Although even if every 1M block was fragmente still the metadata layout would fit in the metadata buffer, there's plenty of room there.
We have tested XSIDiff with files way over your size without issue, we just could not reproduce your problem.
Try to clone your disks using Vmkfstools to rebuild the metadata layout that should help the problem in case the issue is related to that.
Yes, there will be a discount equivalent to what you paid for your Pro version. You are right the DC version simplifies things a lot as it only has two methods: --backup and --replica.
We are taking the time to test it in the multiple combinations that ESXi can generate since v 5.1.0 although as it mainly relies on GLibC that makes it more stable, it still relies on the underlying ESXi folder and descriptor files structure.
We should be able to launch by middle August.
You are duplicating your posts, that won't get you more support.
Since the moment that you consider that using an Atom processor should not hurt SSH performance and you are not even open to reconsider your position, I'm afraid there's not much we can do for you.
That's normal. XSIdiff can only jump over zero zones when the underlying FS is VMFS. In case of full local backups being performed on non VMFS volumes, use Vmkfstools or Onediff for differential backup, in case of the latter the Onediff routines will take care to choose the best binaries for the matter.
Are you by any chance using NFS4?, NFS4 does not work in the ESXi shell context.
Apart from that try to reboot your servers.
When XSIBackup finds a VM in a non VMFS volume it just warns, as it won't be able to jump over zeros and the throughput will be limited to nominal network link speed and thus the backup will usually take much longer.
If there aren't any further errors you can sefely ignore the error.
[url=https://33hops.com/xsibackup-most-common-issues.html](c)XSIBackup most common issues[/url]
Those are just comments, they should not affect functioning. We'll take a look at this part and eventually publish any relevant information.
All XSIBackup keys are RSA, they have not changed since long ago when they use to be DSA. We don't know what you mean by OPENSSH format.
Latest versions of XSIBackup-Free incorporate those improvements as well, this is the full output of a test we just made using a GMail account
###############################################################################
#
# (c) XSIBACKUP-FREE 11.2.6 | Backup for (c) VMWARE ESXi Hypervisor by 33hops.com
#
###################################################################################
--------------------------------------------------------------------------------------------
| High speed and deduplication is not available in XSIBACKUP-FREE |
| Get XSIBACKUP-PRO at https://33hops.com |
--------------------------------------------------------------------------------------------
Using stored SMTP server info...
Found conf/smtpsrvs file...
Using SMTP server #1: smtp.gmail.com:465
Open firewall: Firewall rule SMTPout-465 added...
USING KEY: xsibackup_id_rsa
CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=smtp.gmail.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEijCCA3KgAwIBAgIQMZyM27r8bQxIFPEmL64pejANBgkqhkiG9w0BAQsFADBU
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMSUw
IwYDVQQDExxHb29nbGUgSW50ZXJuZXQgQXV0aG9yaXR5IEczMB4XDTE5MDYxODA4
MjQ0M1oXDTE5MDkxMDA4MTYwMFowaDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNh
bGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2ds
ZSBMTEMxFzAVBgNVBAMMDnNtdHAuZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEApklWJnKp8tikE9yoE5US4lLEhRaW3p6MzmFn60On1Bme
whfOWe5juSS+d+it3a/f9ZdG7Bp3TBM509lkHmOS5ohVzbPhcHzCqgzhx4BvCYml
mmeBs29+6E4CfgJ0iLv2pq/vRzIZOTsLCdLBs9LY1YP48UsOHcopY7BTnaa6kfH2
01tPx958CqGd+T/lDZnbdq4uIxuVoVCr10gr+B8Im8RUUdUDXPnL77ggObdzW6TI
dCdFL4L95dYAcrg2QTEGnquOqJLjzKHLFEjdGYmcghSq0usx26oz5xJw6kEQWyMt
UsBr4v1RRqrgawl0gh3LlGlhR+IiJHCQe3muP+t2GQIDAQABo4IBQjCCAT4wEwYD
VR0lBAwwCgYIKwYBBQUHAwEwGQYDVR0RBBIwEIIOc210cC5nbWFpbC5jb20waAYI
KwYBBQUHAQEEXDBaMC0GCCsGAQUFBzAChiFodHRwOi8vcGtpLmdvb2cvZ3NyMi9H
VFNHSUFHMy5jcnQwKQYIKwYBBQUHMAGGHWh0dHA6Ly9vY3NwLnBraS5nb29nL0dU
U0dJQUczMB0GA1UdDgQWBBRj0fwI8zIjVe20RCIYXeZ9ff6igzAMBgNVHRMBAf8E
AjAAMB8GA1UdIwQYMBaAFHfCuFCaZ3Z2sS3ChtCDoH6mfrpLMCEGA1UdIAQaMBgw
DAYKKwYBBAHWeQIFAzAIBgZngQwBAgIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDov
L2NybC5wa2kuZ29vZy9HVFNHSUFHMy5jcmwwDQYJKoZIhvcNAQELBQADggEBAFIW
bq0RSackQcMqGuYEyqezErVEje9DimpyMSGfyH2QjnwU2BUYSgzQLVcfddxXCzYM
6tPEEkuyNE0ZlVnZBhGMrLcoCY35HEhBRf1COFalYpA4AulqQQ7mo49nVvxQEEyG
IF5BgOPDeeoKxdgUPvrayJNS2dEyXXZIWDbpuPymDi1a2sp/wfqzi1l4yFqJOaT4
8n8nDGfSjg8LniCA7/khuPbahJ7FH9wP4VSLVLg9MxBTdMcy4a/scPx0bFe2GzMZ
zi2Q3/MWRkubKrEvjz3cHHIT3ycZimoKIgYeXuRQzKKw1//fd/gb8h1OeRLSzw0U
4hHCTRhGSI9QglEdbRA=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=smtp.gmail.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
---
No client certificate CA names sent
---
SSL handshake has read 2994 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 9E08E9DD0DCE43510EAD0818918337520D32BA99DB27E9BC877DEE1C92C20BD4
Session-ID-ctx:
Master-Key: 2C49ABD196C7B824EB41628DAD61CAAC382035AEC3627BC427A614CED808DF88A7BF912E0E6D7650BC3E58F1DDBDCE00
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 00 5b 03 a7 22 ba 79 6b-f1 33 73 25 9a 37 d9 10 .[..".yk.3s%.7..
0010 - e0 0a c8 8f ba 7c 06 75-02 ba 0c bc 14 59 99 0e .....|.u.....Y..
0020 - 39 85 bc b0 f2 27 be 02-19 ed a8 88 e8 82 f0 47 9....'.........G
0030 - b4 24 00 f3 3f 94 e5 c8-f1 e8 c5 d4 55 11 86 7b .$..?.......U..{
0040 - 25 5c 93 f6 f3 26 a3 bc-3e af 0c 1b fe 72 b6 eb %\...&..>....r..
0050 - 85 4c 6c 41 7a 58 e3 5c-df 13 f8 e7 cc be de 91 .LlAzX.\........
0060 - 5c 5e f2 5b f0 c5 75 0c-07 dd 31 65 17 c2 76 b8 \^.[..u...1e..v.
0070 - b4 d5 6a 3e a2 87 cb be-cb 73 d8 d6 6f e5 ce 10 ..j>.....s..o...
0080 - 14 b3 51 a7 57 2d 29 b4-f2 16 03 ef 21 6a 11 27 ..Q.W-).....!j.'
0090 - af 47 ea ff e2 5a 56 40-c3 bb a0 e4 57 9a ed d9 .G...ZV@....W...
00a0 - fc 25 91 78 bb 15 01 77-69 f7 a8 9e 85 cc 71 42 .%.x...wi.....qB
00b0 - 5a f5 cc 1f fb 11 26 e3-ae 51 45 a8 d8 09 09 ac Z.....&..QE.....
00c0 - 87 e1 44 6f 9f 59 bf ca-dc 40 80 03 2d 03 82 6e ..Do.Y...@..-..n
00d0 - 6d 34 16 ce 2c m4..,
Start Time: 1563812544
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
220 smtp.gmail.com ESMTP w23sm40668660wmi.45 - gsmtp
250 smtp.gmail.com at your service
250-smtp.gmail.com at your service, [88.26.235.134]
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
334 XXXXXXXXXXXX
334 XXXXXXXXXXXX
Firewall rule SMTPout-465 closed.
KilledThere have been some changes in OpenSSL lately and this affects the way keys are exchanged with e-mail servers. We have addressed this in latest versions and it is working with GMail for us and other clients. Please, contact suppport to receive personalized support, it is included for Pro users.