Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Yes, you just need to mount the .vmdk file to any VM and copy the file wherever you want.

Can you offer some more details?, namely: backup job string and complete output log.

[b][https://33hops.com/xsibackup-pro-onediff.html]OneDiff[/url][/b] works both: "locally", which in this case means from a locally attached datastore to another locally attached datastore and, over IP, namely, OneDiff moves the differential data from a local datastore to any other ESXi host reachable over IP. Obvioulsly to any local path attached to that remote server, but I should not need to especify that, it's implicit.

[b]Other end[/b] means the target device, whatsoever will be receiving the data being backed up. If I use the expression [i]other end[/i] and do not especify whether it is a local datastore or an ESXi server on the other end of the world, reachable by IP, then I'm using a vage term deliberately, because I'm talking in conceptual terms and I want to leave that option open.

If you perform a [b]OneDiff[/b] backup to a remote server (reachable over IP), you then have a VM which has been mirrored and is an exact copy of the VM that it mirrors, and that is ready to be swicthed on, thus a usable VM from all points of view. That VM is on a different host than the production ESXi host where the VM being backed up was, and thus the [b][https://33hops.com/xsibackup-pro-onediff-backup-retention-policy.html]referenced post[/url][/b], which is written in a [b][url=https://en.wikipedia.org/wiki/Socratic_method]maieutic[/url][/b] style, states that you can then chain a backup, to be performed once the first backup finishes, that is what the term [b]link[/b] means.

That additional backup can, and it's what the post proposes, be an XSITools backup, which will archive the just backed up VM to a repository. As the first backup which we will be using as the source of the second is in a different ESXi host, and maybe even in a different datacenter, the load associated to performing that second backup, won't interfeere with the production ESXi host.

A repository is a storage format that hosts data, like a .zip file. In this particular case, hosts the chunks of data that compose the XSITools deduplicated Virtual Machines. VMs stored in a repository cannot be used directly, as they are not in an operational state, just like a file cannot be used when it's stored in a .zip file, it first needs to be extracted, or in the case of an XSITools repository, restored.

You don't need a previous backup to backup to Borg, you can do so directly. The drawback is that XSIBackup will send [b]all data[/b] to the Borg server. There's currently no possibility to run a Borg client in ESXi.

Yes, you can VMFS format your NFS volume, but the fact that you can does not mean you must, or that using a different File System is not correct.

[url]https://pubs.vmware.com/vsphere-6-0/index.jsp?topic=%2Fcom.vmware.vcli.examples.doc%2Fcli_manage_storage.6.9.html[/url]

Before choosing the file system you'll be using in your NFS attached device you should take into account some considerations:

- Will it be useful to use VMFS?
- Are there other File Systems you can use?
- Do you have some advantage by using a different Filesystem like ext4, btrfs, XFS, etc...?

If you want to use that NFS attached datastore to host deduplicated data, that is compounded by thousands of indexed small chunks of data, you may decide that XFS or ext4 are best choices than VMFS, as they can handle many times the amount of inodes that VMFS can.

Well, in sake of speed I would backup to a different physical disk or array, if you can make it be a different datastore at the end of an NFS share better, as you will, on addition, count with some sort of physical distance between your main datastore, where the production VMs are, and your backups.

To protect backups against a physical theft, just use encryption in your backup file system.

a - openssl sha1 yourfile
b - openssl md5 yourfile
c - openssl md4 yourfile

Of course you have to run any of those commands on both sides and compare the obtained checksums. You may need to switch off your VM to perform the backup and the manual checksum comparison, as a running VM could change the contents of the open disks.

Well, first of all you need a fixed IP or a "kind of". You may use one of those Dynamic DNS services to get a fixed domain name:

- [url]https://www.noip.com/free[/url]

Mac OSX is Unix, but not compatible with Linux binaries. You could use Rsync on the Mac side, but that would force you to use a close version to 3.1.0 to prevent Rsync protocol errors, and even if you succeded, it would be slow.

I think your best bet would be to just use a Linux VM running on your Mac connected to your storage pool. You can download a free .ova package here: [url]https://drive.google.com/open?id=0B5o7NiDeLLWSbzlON2szTWZyUTg[/url]

This Linux VM can run with as little as 512 mb. of RAM and still offer you maximum speed when connected to any NFS or iSCSI device. That way you could use, XSIBackup's bundled Rsync and XSIDiff and store the backups to your RAID.

Depending on your connectivity possibilities in regards to the mentioned RAID, your options would range from adding virtual disks to your Linux VM and host them in the RAID, to connecting a minimal VM to your RAID as a raw device and use it just as a passthrough device.

Yes, you can remove that line (and any other related one) if you are confident you want to remove that disk. I would sanitize the .vmx file prior to posing any other later action.

A corrupt configuration file can cause all sort of unexpected results, not only from part of XSIBackup, but from any other program accessing the VM like the vSphere GUI, vCenter, vCenter Converter, etc...

Run this and note the output

cat /vmfs/volumes/datastore1/BKPMAN/BKPMAN.vmx | grep ".vmdk"

XSIBackup just collects the information present in the configuration files

It works for us, it's a pretty simple script. Have you enabled DNS in your ESXi server?.
If you can't fix your network issue, just download and install manually, it won't take you more than a couple of minutes

[url]https://33hops.com/xsibackup-tutorial-1.html[/url]

Yes, XSIDiff, which is a binary utility, and from the scope of the XSIBackup framework will just substitute Rsync in the first stage of an IP backup, will work the same with a turned off VM.

You have other choice, which is to use a [b][https://33hops.com/xsibackup-help-man-page.html#backuphow]warm[/url][/b] backup. This is just a cold backup, but the VM is turned on right after taking the snapshot.

Mmm, we'll review that check, it is very rare that the first 50M block is empty

[url=https://en.wikipedia.org/wiki/GUID_Partition_Table]https://en.wikipedia.org/wiki/GUID_Partition_Table[/url]

In any case, in the end it is up to VMWare and Microsoft to decide whether they allow empty space at the beginning of a physical disk. I'm not surprised that MS installer would generate such GPT partition, who else would?

We'll make thorough tests and will remove that check for MS OSs if, as it looks, they behave in such way.

Great!. ESXi is far from perfection. It sometimes fails at performing the simplest things.
The downloads dir should be created automatically.
We'll improve this piece of code to double check this fact.