Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Thank you for your feedback.

As per current design, a local datastore, and that can be some NFS/iSCSI volume, is considered a local FS, with all its consequences, being the most important one that latency in general (disk+network) iwill be considered to be that of some local device.

Depending on your network hardware and your real scenario, that network latency added to I/O operations can sum up and reduce your effective I/O speed as you describe, as the backup behaviour is synchronous for local backups.

This does not affect replicas, as they are performed in a totally different way: replicas write some file's data to the same remote file, there aren't any seek times or file creation times associated to I/O as there's only a block to write to, namely: the VHD file.

The way to improve speed if you need more is to perform the --backup action over IP or to reduce the datastore access latency by using a locally attached device (some local hard disk).

The best target for some over IP backup is a Linux FS. Devices like Synology or QNap are great for novices, or if you need some easy to configure NAS, still, they won't allow you to configure them as a Linux box would do. They are propietary environments and they seem to have the will to become even more propietary in the future.

We offer an easy to deploy virtual appliance that you can use to configure some backup VM over virtual disks:
[url=https://sourceforge.net/projects/xsibackup-nas/files/](c)XSIBackup-NAS[/url]

Or you can use any distro of your choice. CentOS or Debian are the best choices for us.

In regards to adding local storage attached to a local controller: as you probably already know VMFS-6 is not a good FS to store deduplicated backups, primarily because it's slow, it wasn't designed for speed. Thus you need some XFS or ext4 FS to store the backups.

A good way to have a local disk with some XFS or ext4 file system is to create some locally attached RDM disk with [b]vmkfstools[/b]

vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST500DM0000022DD142__________________________________
_W2APL5M4 /vmfs/volumes/datastore1/MY-LINUX-VM/RDM01.vmdk

Add it to the Linux virtual machine.

Then format it as XFS or ext4 from the Linux VM, this will allow you to access some locally attached disk that you can mount as NFS or access via IP from within the local IP space of the (c)ESXi host, with almost no latency and 10GB virtual NICs.

We will write a post on how to prepare such device in some days.

In regards to these errors:

2021-08-27T18:53:30 | Error code 1474 at file common.c, line 1474 | Error description: error running command, returned: 127
-------------------------------------------------------------------------------------------------------------
2021-08-27T18:53:30 | Error code 1499 at file common.c, line 1499 | Error description: could not get remote FS available space at /vmfs/volumes/nfsdatastore/Test, details: No such file or directory
-------------------------------------------------------------------------------------------------------------
Available space in backup volume:           -1 (17179.87 PB)

They can happen when backing up to some ESXi builds that come with a somewhat broken OpenSSL implementation. We have removed that dependency in version 1.5.1.0 so that compatibility is extended to almost any build of ESXi and Linux.

Regarding the creation of repositories in the root of a volume: NO, don't do that.
Leaving aside all considerations regarding less experienced users, which count and do count a lot, assuming that you are a really experienced sysadmin: why would you want to do that?, what is the advantage of doing so?:
What if tomorrow you want to create another repository in that volume?
What if you need to add some replicas to the volume?

Through the years we have seen all kind of situations in which people were creating nested repositories, copying replicas inside repository folders etc..., we got to the conclusion that we had some responsability in helping users to maintain some minimum order. Preventing weird things from happening is part of that responsability.

Yes, we know that. It's due to the fact that up until some point in the job, the folder name is used versus the VM name at some other points. We will fix this behaviour.

Still, until we do (this does not affect the backups) try to rename things to keep a coherent naming convention: i.e. if your VM is named MY-VM, name the folder where it resides as MY-VM too, as well as the VHD files.

The speed is calculated on the nominal size of the files, like every other piece of software.

Your NFS volume seems to have disconnected somehow. You need a stable remote FS to perform backups.
If your datastore is not reliable there's nothing any software can do to help that.
Revise cables, NFS parameters, perform some big file copy and check its integrity...

Also, please, do make sure that you store deduplicated backups to repositories in subfolders, never use the root of any FS or volume as the repository root.

That's not how you make room in a deduplicated repository. You have to use the --prune action:

./xsibackup --prune /vmfs/volumes/backup/some-repository/20210330100333

Now that you deleted the .map files, there is no way to know which blocks are exclusive to your new set. Start a new repo.

Yes, you are right. We have already scheduled that feature, still it's not that easy as to impede replication depending on the SMART status, as it's for the main part an statistical analisys matter.

We could add some more flags so that the user can decide at which point to start considering a disk as faulty, still we still have a long way to go improving the main features of (c)XSIBackup, namely: produce backups and replicas, do it faster and more reliably, specially in doing it faster.

We will do so.

You have a missing "\" in the line before the last in your job.
We'll check the error count issue, it most probably has to do with the count base.

The heading of our answer was a generic notice on Classic versions. Still, the same applies to DC. (c)XSIBackup does not produce the snapshot on its own, it is indeed the snapshot subsystem of (c)ESXi that does.

This is a common question regarding quiescing DB systems. We have prepared a specific post on that matter with links to resources. You do need to configure your Windows guests to allow quiescing the DB server.

[url=https://33hops.com/troubleshooting-windows-snapshots-in-esxi.html]Quiescing Windows OSs[/url]

As stated, quiescing a database server is not something you can achieve by just appending --quiesce to the job, it requires that the guest is previously prepared to be able to complete the quiescing flawlesly.

Each version of SQL Server may differ in the way quiescing is achieved, although it will generally imply installing and configuring general VSS services and other especific to SQL Server VSS.

We cannot support manufacturer versions. DELL's is among the best that we have known of so far, still, they contain arbitrary changes with respect to the official VMWare build, thus, they cannot be considered to be the same build.

Some others that we have had the chance to use were an absolute catastrophe by modifying or even disabling some key features.

You can compare on your own by running the same set of commands in an official VMWare build. We will always make sure that all features work in these official builds.

This builds are said to be an optimization, there isn't any better optimization than being in the official VMWare compatibility list though, the thing is that they are just a commercial twist aimed at giving an advantage to the same manufacturer's solutions versus more general ones, that includes paid support.

We'll keep an eye on it. Still, we have sucessfully restored from your same Ubuntu version to your very same (c)ESXi build. We wonder where the issue could be, it looks like something trivial though.

Are you sure you are pressing the <Select> button once you are in the VM dir?. You can press <Select> even one level above, and the GUI will look for the .vmx file recursively. In case more than one .vmx file (VM) is present, a list will be shown for you to select from it.