Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Maybe multipathing is the culprit, not an expert, but some round robin splitting system calls could be an issue. There should be some option for this in the iSCSI client configuration.

Please post some output/ example, we can't figure out what you mean with enough precision to offer a detailed answer.

Thank you for your feedback, we'll study adding a report at the end of --check & --repair options.
In regards to detaching, nothing prevents you from sending the job to the background:

# Send to the background, keep connected to the current 
# terminal though (the job would end if you close the TTY).
xsibackup --repair /path/to/repository &
# Send to the background & detach from current TTY
nohup xsibackup --repair /path/to/repository &

You are right, there's room for improvement in the log, we'll dedicate some time for it in the 1.5 branch.
Current log is just the output of the program, that's why it contains decoration, as it is thought to be monitored with [b]tail -f[/b], you have an independent properly formatted log for errors (error.log)

New (c)XSIBackup Pro&DC are even more flexible than its bash script predecessors, nonetheless, they follow a Linux design, thus, they expect paths to follow Unix style conventions.

There's nothing preventing you from using any target that can be written in a Unix path style. Of course the target FS will play a role in determining the effective speed at which things work and how reliable your backups are. You can use NTFS, it's not our favorite FS, it should work though.

Instead of trying to use a Windows letter based path, use WLS (Windows Linux Subsystem) or even better something like [b][url=https://www.cygwin.com/]Cygwin64[/url][/b] or [b][url=https://sourceforge.net/projects/mingw-w64/]MinGW64[/url][/b]

SIGTERM (13) is a BROKEN PIPE error. It means it was the remote side that requested the SSH tunnel to be closed, thus you must inspect the remote side's error log to find out which was the exact cause why the tunnel was shut down.

If you get many of these errors, then that is a sign that your link is not stable. The remote replica or backup are deleted to prevent storing garbage.

(c)XSIBackup does some high level checks on the state of the VMs and will return errors for the most obvious ones. You should keep your server in a good working condition before attempting to perform any kind of backup.

Error 439 in your case, error codes might change, as they are related to the line where they were raised, means that you removed some VM directory manually but you forgot to unregister the VM from the inventory, thus you now have a ghost VM registry pointing nowhere.

Of course, if (c)XSIBackup can't find the disk, don't even try to restore.

First of all update to the latest available version, we are constantly improving the software.
If the problem persists:

1/ Paste the output of: [b]ls -la /vmfs/volumes/[/b]. Do not remove the last slash, it's fundamental.
2/ Paste the output of: [b]esxcli storage vmfs extent list[/b]

And, of course, provide as much information as possible on the job that caused the error:

- VMs backed up.
- Datastores where the VMs are.
- Type of setup: local disk, NFS, iSCSI, FC...

It means that as files are no longer available to be read, the data has to be read from the block device. It's actually a bit faster than reading the files. (c)XSIBackup-DC is considerably faster than Pro Classic in almost any situation.

Thank you, we just fixed it, the change will be available as soon as the cache refreshes.

That is weird. That directory should be created automatically. Maybe somehow you asigned full permissions on the replica folder, but not on the relative root. This can happen if you use some other user than root.

We have checked this feature and it's working fine. The configuration is saved to the cfgbak folder in the same folder as the replica VM directory.

Yes, we know. --backup --add-key, it doesn't matter. Some coomands work, some others don't. In any case, I remember you that you are playing around with some firmware that for some reason you don't want to reveal, thus our possibilities to help you are even more reduced.

You have the --verbosity flag for that, still, it's not the restore that fails, that's just the command you run, you aren't getting to it though.

This is what you must be concerned about.

...
debug3: Not a RSA1 key file xsibackup_id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
...