Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

We really don't know what you are trying to do.
You have removed part of our original command from your post.
Our original proposed command

ssh -vvv -p22 -o ConnectTimeout=30 -o PasswordAuthentication=no -o ChallengeResponseAuthentication=no -o PreferredAuthentications=publickey -o StrictHostKeyChecking=no -i xsibackup_id_rsa admin@nasponte "date"

Yours: the remote command 'date' is missing, you changed it by a 'ls' command. We were trying to determine whether the date binary was there and whether it was returning something.

ssh -vvv -p22 -o ConnectTimeout=30 -o PasswordAuthentica
tion=no -o ChallengeResponseAuthentication=no -o PreferredAuthentications=publickey -o StrictHostKeyChecking=no -i xsibackup_
id_rsa admin@192.168.2.49 -2 "ls /share/Storage/vmimages/SERVER-INT/20210413085226/SERVER-INT"

Replacing the ESXi 5.5 ssh client with 6.5's is out of the scope of the support we can offer you.
[b]You haven't even clearly stated so far what kind of system you are trying to connect to.[/b]

The .vmx file is obviously .vmx.map, the files are deduplicated. You are restoring from a deduplicated repository where the files are represented by their corresponding hashmaps.

[b]Excerpt:[/b]
- You are able to write data to the remote FS, thus SSH is working indeed.
- You are kicked off with a "permission denied" message when you try to restore.
- That very same command is executed remotely when you run the backup and must be printed out in your backup output (we don't know you didn't post it).
- The only difference is that the backup SSH tunnel is openned with a user cipher list while the date probe is run via autonegotiation.
Run this with the original 5.5 SSH client (we added the same user cipher list as in the backup, which is in turn the list you can find at the etc/xsibackup.conf file):

ssh -vvv -p22 -c "aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc
ssh_ciphers=auto" -o ConnectTimeout=30 -o PasswordAuthentication=no -o ChallengeResponseAuthentication=no -o PreferredAuthentications=publickey -o StrictHostKeyChecking=no
-i xsibackup_id_rsa admin@192.168.2.49 "date"

This is really puzzling, we couldn't find out what's going on without revising that unknown system, we can't offer you to do that for you though.

(c)XSIBackup is agnostic in regards to the network topology.
It does use SSH to connect to other hosts, namely: it will create a tunnel by connecting to some remote IP.
It is the routing table that will decide which interface is used to connect to each network address.

[url=https://kb.vmware.com/s/article/2001426]Configure static routes in (c)ESXi[/url]

BTW: do not forget to update (c)XSIBackup to the end of branch version, which is more stable and bug free.

(c)XSIBackup has been designed to work on (c)ESXi and Linux. NAS firmware is frequently built on Linux, still, it's firmware, and has not been designed to allow an administrator to tweak it to his needs, on the contrary, it's specially designed to prevent that.

That said:

In your case you have been able to exchange the admin user key and (c)XSIBackup is able to access its profile and detect the key there. Nonetheless that very same user is being denied access to [b]/share/Storage/vmimages/SERVER-INT/20210408121629/[/b]

We have to recognize our message is a bit misleading
[b]
Server 192.168.2.49:22 is not linked by public key
[/b]

We are just trying to grab attention here to the most common scenario, maybe confounding some users in other cases, we'll revise it.

The exact message from OpenSSH is printed though, which is: [b]permission denied (publickey,password,keyboard-interactive)[/b] and is self explanatory.

If you want more detailed information on the error, although in this case it seems clear that it's just a permission issue on the folder, you can run some ssh command manually using the very same key trying to grab something from that dir and adding -vvv to the ssh client to get extended verbosity. Something like (from the (c)XSIBackup installation dir):

ssh -vvv -i xsibackup_id_rsa admin@nasponte "cat /share/Storage/vmimages/SERVER-INT/20210408121629/*.vmx" | cat > /tmp/your-vm.vmx

UPDATE1:

Although the manual test will shed some light on the issue, we'll revise the specific logic of the --restore command, as there's obviously some difference between them.

UPDATE2:

This is the exact command, translated to the ssh command line that is causing your issue. Run it and post the output (again, from the installation dir).

ssh -vvv -p22 -o ConnectTimeout=30 -o PasswordAuthentication=no -o ChallengeResponseAuthentication=no -o PreferredAuthentications=publickey -o StrictHostKeyChecking=no -i xsibackup_id_rsa admin@nasponte "date"

One of the early probes on the remote system is to simply get the remote date. For some strange reason it's failing for you.

This issue was solved in 1.4.3.3

We have successfully tested [b]1.5.0.0[/b] with up to [b]ESXi-7.0U1d-17551050[/b]. We will run more thorough tests before announcing compatibility with these latest releases. ESXi U2 will still take some weeks.

Thus, your issue must be related to some particular circumstance. Please, offer us more details to try to determine the possible cause.
Maybe some special characters in the name of the VM?

There isn't any reason why it shouldn't work, as both hosts have their own backup folder.

We can't tell by reading the output. (c)XSIBackup-Pro Classic is a script, please debug it, it's very easy, you have the event handling code at the end of the main script.

(c)XSIBackup is a command line tool, thus, apart from the built-in arguments and options you have all the available bash tools to help you achieve your goal.

The below code will return a list of all your available VMs

vim-cmd vmsvc/getallvms | awk -F '[' '{print $1}' | awk '{print $2}'

You can filter them with grep regexp below

vim-cmd vmsvc/getallvms | awk -F '[' '{print $1}' | awk '{print $2}' | awk '{print $2}' | grep -E "^free"

Then just change the new line characters by commas, only in case you happen to have more than one VM in your list.

vim-cmd vmsvc/getallvms | awk -F '[' '{print $1}' | awk '{print $2}' | awk '{print $2}' | grep -E "^free" | sed -e ':a;N;$!ba;s/\n/,/g'

Finally use the above expression to select your desired VMs and pass them to the --backup-vms argument

MYVMS="$( vim-cmd vmsvc/getallvms | awk -F '[' '{print $1}' | awk '{print $2}' | awk '{print $2}' | grep -E "^free" | sed -e ':a;N;$!ba;s/\n/,/g' )";./xsibackup --backup-point=/vmfs/volumes/datastore1/backup --backup-type=custom --backup-vms="$(MYVMS)"

This is about the same than our REGEXP function does, you keep control on what's going on though.

We could very easily make (c)XSIBackup take a snapshot on a stopped or suspended VM too, or even make it a configurable thing. We are just setting some basic thing: "the rules of the game are not going to change amidst a backup cycle", which is, from our perspective, something not only reasonable but desirable in a hypervisor meant to run servers.

Thus, our software is perfectly able to do what you want. Just keep your VMs on at all time. That way you will follow the basic and most simple rule: not changing the VM state in the middle of a backup job. You will be able to use it while it's being backed up without any problem.

What you are claiming is something totally different which has nothing to do with the ability to perform hot backups, namely: [b]being able to change the state of a VM in the middle of a backup[/b].

And the answer to that statement is very simple and straight: [b]no, we don't offer that feature nor do we pretend to[/b].

Would it be interesting to offer it?: well, that would be a difficult rethoric question to give an answer to. I guess there should be a previous question to place ourselves first: is there some good reason for it?, is there some significant number of users asking for that feature? or at least some case scenario or common situation in which that would be useful.

All routines have been thought to be as crash consistent as they can be. Per instance: blocks are copied over as a temp buffer and only once the transfer process is confirmed to have finished well, they are put in place with an atomic system call.

The new blocks are only added to the general .blocklog manifest once the full (1)backup process has finished. They are added to the file manifest (.map files) on a per file basis. Thus, if some backup is interrupted, the blocks will be copied again on any subsequent backup, as if they didn't exist, unless you run some --repair argument in the backend, which would account the blocks on the partial files to the .blocklog file and eventually save you some time.

All this operations follow rule of thumb logic, that is: if some block can't be completely transferred, it will not appear as a file in the data folder as part of the block structure. If it is not present in the data folder, it will not be considered by the --repair process.

You have the --check action to allow you to check the data block structure at different levels: file exists or file exists and its checksum matches the name of the block.

In regards to the --replica action. It writes data to the same file on the backend. In case anything would go south, you would get warnings and errors at different levels: 1/ the block transfer, 2/ the final checksum (number of bytes transferred).

By "reductio ad absurdum" logic: the possibility that a block is transferred wrongly while not getting an error on any of those two levels of check is extremely low, not to say despicable.

In case some replica is altered or damaged, you can use the --check action on it, which consists in checking every constituent block and rewriting the correct checksum to the corresponding .blocklog file. Thus next time a --replica is performed on the remote mirrored image the blocks which checksum doesn't match will be updated.

You could still suffer from silent corruption on the disk side. This is infrequent and tends to be much more frequent as read errors than writes. You should rely on your SMART utilities to be safe from that kind of problems.

Still there's room for more refinements and additional checks on the data and that's what we are planning on doing as our software evolves.

You are probably right, we are trying to make the manual as concise and practical as possible, many users don't even read it.

We will inlclude this kind of information in an appendix once we have reached a final stable phase at the end of branch 1.5 (which is about to be launched). Right now the evolution of the software is very fast and some things as: whether this information should be printed out or not is still under discussion and may be subject to change.

It does not affect your backups or restores in any way though.

(c)Synology has been drifting away and making its DSM OS more and more closed and propietary. Up until not so long ago you were still able to use the root user over SSH. In fact they started by limiting SSH access to the root user while prohibiting any other user from accessing via SSH.

Now they seem to have taken some additional turn, we'll investigate this and if that is the case we'll remove the Synology compatibility notice and update the warning on the related posts.

This doesn't mean that you can't make (c)Synology work with (c)XSIBackup. Just as long as you can exchange keys and access via SSH with some user you will be able to. It will nonetheless require you to:

1 - Know how to exchange SSH keys manually in the worst of the cases. This is conceptually fairly simple (see above answer), just add the public key of your frontend (c)ESXi host to the [b]authorized_keys[/b] file of the Synology DSM user you will be employing over SSH.

2 - Know where the .ssh profiles are stored. This is configurable in DSM. You normally store them in /volume1/homes, it could be anywhere else though.

3 - Use the --home-path argument from (c)XSIBackup to point to the place where the authorized_keys file is.

In a typical DSM setup you would have your admin user's authorized_keys file here:

/volume1/homes/admin/.ssh/authorized_keys

Then use the above bash code snippet or use the --add-key argument along with the --home-path option.

Once you have added the public SSH key you just have to check whether the key exchange authentication is working by issuing something like the following:

ssh -i xsibackup_id_rsa user@a.b.c.d "date"

Where the xsibackup_id_rsa is the private key. You should see the date printed out.

Now you just need to make sure that the user you will be employing has execute permissions on the /bin/xsibackup binary, the /var/log/xsi and /etc/xsi folders and off course on the folder where you will be storing your backups and replicas.

Given that on (c)Synology the admin user is the most privileged one, this last phase should be quite straight.