©XSIBackup-Free: Free Backup Software for ©VMWare ©ESXi

Forum ©XSIBackup: ©VMWare ©ESXi Backup Software


You are not logged in.

#1 Feature requests & improvements » Replica bug » 2019-11-03 02:41:40

srwsol
Replies: 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.

#2 Re: General matters » Is DC a trial? » 2019-10-16 23:41:28

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.

#3 Re: General matters » Backup solution question » 2019-09-19 15:53:22

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.

#4 Re: General matters » Backup solution question » 2019-09-19 03:31:41

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

#5 Re: General matters » Backup solution question » 2019-09-15 19:54:30

I can't use vmfsktools because it deletes the snapshots on the backup, as I already tried that.

#6 Re: General matters » Backup solution question » 2019-09-15 19:50:07

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.

#7 General matters » Backup solution question » 2019-09-15 03:33:36

srwsol
Replies: 9

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?

Board footer