You are not logged in.
Pages: 1
Hi folks:
I was working with the trial version 1.0.0.5 testing out replicas, as that's how I intend to do my backups. I made replicas to a local datastore and then to a NFS share, verified that it indeed kept thin vmdk files thin, and I did sha1sums on all the files and compared both to ensure the copy was valid. All was good. I then tar compressed the VMs, gzipped it, and then ran the process in reverse to restore the files, first to a NFS share from a Linux VM (ESXi's version of tar doesn't handle sparse files) and then used xsi (running on ESXi directly) to replica back from the NFS share to a local datastore. Here is where I ran into an issue. The VM I originally used for the test was down when I made the replica, but when I went to copy a replica of the VM from the NFS back to the local datastore, but to a different directory, because the VM was up xsi skipped one of the snapshot disks indicating that it was "excluded". At first I couldn't figure out what was going on, but then when I shut down the original VM again and ran the replication back to the local datastore, it worked.
Apparently xsi is looking in the .vmk file to identify the VM involved and thinks that because the VM is running it can't fully replicate. However, it doesn't realize that the replica is being put in a different directory than the running VM is in, and therefore it shouldn't be paying any attention as to whether the VM is running or not. I'd suggest either making it smarter and able to know if the directory that the VM is going to is really the one that a running copy of the VM is using, or adding an option to the --backup-how option or perhaps creating a --restore-how option to tell it to just replicate without checking to see if a VM of the same name is running.
Also it would be good to have a way to tell xsi not to create the .map directory, as if one is simply doing a point in time stand alone backup via replica, which is how I intend to use it, it's unneeded as far as I can tell and just wastes space.
Is the 6 hour limit clock time from the moment you install it or after a host reboot, or is it 6 hours of total run time for the program? I'm about to conduct some tests, but if it's clock time, then I have to make sure I have a large block of time to work with it all at once.
Edit:
OK. I read in another thread that there was a way to remove the 6 hour time limit and just go with a 60gb limit on the size of the VM. That may be sufficient for my testing purposes. However, it wasn't clear from that thread whether I have to actually do something to remove the 6 hour time limit, or if it was removed from the trial version completely and the readme file just wasn't updated.
How much does the datacenter product cost? I couldn't find a price on the website. I'm a single person consulting business with just one VMWare Essentials license, so price is a factor. I have a number of VMs with over 60gb of data, so the free version won't work for me.
I just tried using onediff and it did not preserve the snapshots. I backed up using this command:
/vmfs/volumes/553f5adb-199bdfe4-29b3-001e67ca647e/xsibackup] ./xsibackup --backup-point=/vmfs/volumes/5d7c6d59-6e45dae4-813a-001e67ca647e --backup-prog=onediff --backup-type=custom --backup-vms="LH Ubuntu Server 17.04" --mail-from=zzzzzzzz@yyyyyyyy.com --mail-to=xxxxxx@yyyyyyyy.com --subject=xsibackup --test-mode=false --smtp-srv=10.172.187.253 --smtp-port=25 --smtp-auth=none --smtp-usr=xxxxxx@yyyyyyyy.com --smtp-pwd=any
Here is the source directory:
[root@intelserver:/vmfs/volumes/553f5adb-199bdfe4-29b3-001e67ca647e/VirtualMachines/LH Ubuntu Server 17.04] ls -l
total 23263240
-rw------- 1 root root 520163328 Sep 16 02:45 LH Ubuntu Server 17.04-000001-delta.vmdk
-rw------- 1 root root 347 Sep 15 16:27 LH Ubuntu Server 17.04-000001.vmdk
-rw-r--r-- 1 root root 53 May 1 2017 LH Ubuntu Server 17.04-60dd9dc9.hlog
-rw------- 1 root root 28785 Sep 15 16:26 LH Ubuntu Server 17.04-Snapshot8.vmsn
-rw-r--r-- 1 root root 13 Sep 15 03:18 LH Ubuntu Server 17.04-aux.xml
-rw------- 1 root root 34359738368 Sep 15 03:17 LH Ubuntu Server 17.04-flat.vmdk
-rw------- 1 root root 8684 Sep 16 02:45 LH Ubuntu Server 17.04.nvram
-rw------- 1 root root 587 Sep 15 03:17 LH Ubuntu Server 17.04.vmdk
-rw-r--r-- 1 root root 55850 Sep 14 06:35 LH Ubuntu Server 17.04.vmdk.extents
-rw-r--r-- 1 root root 433 Sep 15 16:26 LH Ubuntu Server 17.04.vmsd
-rwx------ 1 root root 3383 Sep 16 02:45 LH Ubuntu Server 17.04.vmx
-rw------- 1 root root 150 Sep 15 03:12 LH Ubuntu Server 17.04.vmxf
-rw------- 1 root root 399866 May 28 02:53 vmware-32.log
-rw------- 1 root root 256628 May 30 21:19 vmware-33.log
-rw------- 1 root root 387940 Sep 10 03:06 vmware-34.log
-rw------- 1 root root 255566 Sep 14 02:54 vmware-35.log
-rw------- 1 root root 256538 Sep 14 04:37 vmware-36.log
-rw------- 1 root root 255372 Sep 14 06:13 vmware-37.log
-rw------- 1 root root 285407 Sep 16 02:45 vmware.log
And here is the destination directory after the backup:
[root@intelserver:/vmfs/volumes/5d7c6d59-6e45dae4-813a-001e67ca647e/LH Ubuntu Server 17.04] ls -ls
total 22745096
22744064 -rw------- 1 root root 34359738368 Sep 19 03:00 LH Ubuntu Server 17.04-flat.vmdk
1024 -rw------- 1 root root 8684 Sep 19 03:00 LH Ubuntu Server 17.04.nvram
0 -rw------- 1 root root 587 Sep 19 03:03 LH Ubuntu Server 17.04.vmdk
0 -rw-r--r-- 1 root root 446 Sep 19 03:00 LH Ubuntu Server 17.04.vmsd
8 -rw-r--r-- 1 root root 3383 Sep 19 03:03 LH Ubuntu Server 17.04.vmx
0 -rw------- 1 root root 150 Sep 19 03:00 LH Ubuntu Server 17.04.vmxf
I can't use vmfsktools because it deletes the snapshots on the backup, as I already tried that.
OK, how would you recommend I use XSIBackup to achieve what I need? I don't mind upgrading to the Pro version if that's what it takes to get it to work how I want it to.
Are the files within the VM's directory on the backup binary identical to the actual VM files, or are they somehow tied to all this extraneous data? If they are identical, I can just delete the data directory.
I'm playing with the free version of XSIBackup and I've got a question about how to accomplish what I want. All I want from a backup solution is to copy every file in a VM (snapshots included) while preserving the "thin" aspect of the vmdk files, to another location, either a separate datastore attached to the host (i.e. another disk), or to a linux VM via NFS, Samba, or any other method linux supports. I want only a single point in time full backup (i.e. I won't be doing incremental or differential backups) for offsite archive purposes.
I tried using --backup-prog=xsitools and it appeared to do what I want, with the exception of all these extra files in a "data" directory. From reading the documentation, if I understand this correctly, the information in the data directory is somehow used to avoid duplicate data transfers, which I'm not sure I fully understand how it works. There was some discussion about the issue of losing some of that data causing multiple VMs or backups to become corrupt, which is what concerns me. I want each file in the backup under the directory name of the VM to be a binary identical copy of the real file being backed up, so that I can verify the backup by using md5sum or sha1sum against the files.
I'm just a single person consulting business and I only have a single ESXi essentials license, and I do this full archive only once a quarter (I have other methods of backing up volatile data) so that I have a reasonable starting point for my other backups if I lose my ESXi server and have to start from scratch. That means I don't have a problem doing some of this manually just so long as I can get exactly what I want.
Is there a way I can do this with XSIBackup?
Pages: 1