Somehow I had several personal projects that required a relatively large amount of disk space - about 2TB. There were no suitable VPS (very few people offer a lot of HDD space), so I took a dedicated server from OVH, installed ESXI 5.5 with a free license, and everything worked.
After some time, with the development of projects, I began to configure admin chips - monitoring, backup, and found out that it turns out the server in which
I was promised Soft RAID, and to which the hoster (OVH) rolled my ESXI image - without RAID! That is just 2 discs. Well, yes, now I know that ESXI does not support Soft RAID, only Hard. It became uncomfortable. Yes, and 2TB was not enough. In general, I took a bigger server for myself, with hardware RAID, and installed ESXI 6.0 there.
And there were two problems, the solution of which I will describe here:
')
- Move virtual machines (some of which are about 1TB) from one server to another with minimal offline
- Make regular backups
I will say at once that both of these tasks are easily solved if there is at least a minimal paid license of ESXI. The fact is that the "native" Backup API in the free version of ESXI is turned off. Therefore it is necessary to find other ways.
With a paid license there is a migration option through
vCenter . There is also a free version of
Veeam Backup , which allows you to make backups and transfer virtual machines from one system to another without having to stop them. But with the free ESXI license, the current version - Veeam 9 -
does not work at all .
There is also a solution from
HP - VM Explorer , which has a free Free Edition.
VM Explorer 6.2 can work with free ESXI, but:
- When creating a backup, the full size of the image is copied from the server, even if the disk is thin (thin). That is, if the virtual machine’s disk is 500GB and only 50GB is recorded there, then 500GB will be copied. And so - every time. The incremental backup mode (only on the local computer) is in the paid version, I have not tested it - I know how effective it is.
- Free license allows you to backup only to local drives. That is, in order to copy to another ESXI host, you already need a paid license.
- In the free version there is no scheduler, that is, you need to run backups manually.
Another popular solution is the open source
ghettoVCB project, but it seemed to me somewhat complicated to use, and the
documentation looks a bit outdated. About this project have already been written here
on Habré .
I am sure that there are many other options. It will be interesting to read the comments of experienced admins. Although I suspect that the experienced ones work where they bought the necessary licenses and are not steaming ...
Here you can simply mention:
- Nakivo , which has a limit of 2 VM in the free version.
- Unitrends , which has a limit of 1TB in the free version.
- Thinware
If you have experience using these products - share in the comments.
I eventually decided to use 2 tools:
Xsibackup
Prior to version 4.4, Xsibackup was on
Github , but now (version 6.0.7) has been removed from Github and Xsibackup, now it’s necessary to install from the authors site.
In the free version:
- “Hot” backups, without stopping virtual machines. This is done using a snapshot (snapshot)
- Configuring cron (cron) in ESXI
- Email Reports
- Backups rotation
- Backup to another ESXI host. In the free version, using rsync, honed for ESXI. In the paid version, there are still incremental backups ( OneDiff ) through the creation of intermediate snapshots (as for me - not a very good solution) and deduplication using their NAS ( XSINAS )
Xsibackup installation instructionsThe same manual is in English -
33hops.com/blog_xsibackup-quickstart.htmlXsibackup is installed on an ESXI host from which you want to make backups.
SSH must be enabled on ESXI.
Register on the authors site - Download xsibackup -
33hops.com/xsibackup-vmware-esxi-backup.htmlYou will receive a free key and a script for installing on ESXI via email:
cd /vmfs/volumes/datastore1/xsi-dir 2>/dev/null || mkdir /vmfs/volumes/datastore1/xsi-dir && \ cd /vmfs/volumes/datastore1/xsi-dir && \ esxcli network firewall unload && \ wget http://a.33hops.com/downloads/?key=64cG...secretKey -O xsibackup.zip && \ unzip -o xsibackup.zip || cat xsibackup.zip && echo "" && \ chmod 0700 xsibackup* && \ rm -rf xsibackup.zip && \ esxcli network firewall load
secretKey you will have your own.
If your datastore is called differently, then you need to register your path.
When someone sees wget, someone can shake their head, and say that putting someone else’s software on an ESXI host is not a secret, etc. However, with any backup, you will give the root password to the program for backup, that is, you will trust someone in any case. When copying locally, Xsibackup uses only shell scripts that you can see and check ...
Then create a folder where we will add backups - locally, or on another server:
mkdir /vmfs/volume1/datastore1/backup
If we copy backups between hosts, then we share SSH keys:
./xsibackup --link-srv=[second.esxi.system.ip]
If we want to run backups through kroner, then:
./xsibackup --install-cron
We test that everything works locally:
./xsibackup --backup-point=/vmfs/volumes/datastore1/backup --backup-type=running --mail-from=email.sender@yourdomain.com --mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.yourserver.com --smtp-port=25 --smtp-usr=username --smtp-pwd=password --test-mode=true
To test work between hosts, we change:
--backup-point="IP-OF-ESXI:22:/vmfs/volumes/datastore1", 22 - SSH .
If SMTP requires TLS, then --smtp-sec = TLS is supported.
»
Full list of options (in English)
Locally, that is, on the same host, everything works fine: backups are done using the native ESXI utility,
vmkfstools . Everything is fast, and thin disks remain thin. With hard drives, I got a speed of about 60MB / s
However, when copying to a remote host, I found the same problem as with HP VM Explorer — the full size of the VM is copied, even if the disk is thin and only a smaller part is used.
When I asked the authors what the reason was, they wrote that rsync is used for copying between hosts, and he is not smart enough to skip unallocated blocks of thin disks.
When testing, I found that with repeated backups, rsync practically does not shorten the copying time - the full size of the VM goes back over the network.
The authors wrote that they had plans to file their own utility instead of rsync, which would be much faster. Plan to release before the end of the year.
In my case, the hoster guarantees a network speed of 250Mb / s (~ 31MB / s), but actually between two hosts in one data center, the backup worked for me at 10-20MB / s. I don’t know what this is about, whether the network slows down, rsync or whatever, but the process takes too long.
Update : I found
an article , - according to their benchmarks, it turns out that it would be faster if it was a braked SSH (on top of which rsync runs).
I am glad that as a result the disks still remain thin.
The process of transferring and backup VMs
The process of transferring VMs between hosts looks like this to me:
In the same way, while the backup VM from the hoster to his home also looks. To do this, ESXI is spinning in my home - so that ovftool can only transmit the payload over the network.
On the
forums they write that there seems to be a way to copy files to NFS with the sparse option so as to transfer only existing data, but I have not figured it out yet.
I did not find a way to make an incremental backup.
While I do everything manually from the console - I transfer it to another host, I make the first backup, but over time, I think everything will be configured via cron. Maybe later I will add here a couple of paragraphs on how to adjust the crowns. Original instructions here:
33hops.com/xsibackup-cron-how-to.htmlThus, now my first copy is near, on the same server, and is available for fairly quick recovery.
The second copy is at my home, that is, as
recommended , in a physically different place. To restore will have to fill the network, which is significantly slower. But the probability of needing this is also quite low.
Ovftool
The complete manual in English is
here , there you can download it. Ovftool can be installed on any computer, and you can control the hypervisor from it. Or you can put a host directly on the ESXI, although this is not a supported feature.
Installing Ovftool on ESXIIn general, the process is as follows: first, Ovftool is installed on Linux x64 (I did on Ubuntu 16), and then the files are transferred to the ESXI host.
Here are the steps:
Ovftool does not know how to copy VM in hot mode, that is, it requires that the virtual machine be turned off. Therefore - the need for Xsibackup above.
Several features of Ovftool work:
- I used to pop up errors: “The task was canceled by a user” or “Error: vim.fault.FileNotFound”. The reason for both errors was that the CDROM on the original machine pointed to the ISO, which was not on the target host. Try to guess about this from the text of the error ... It was decided to remove the CDROM of the device (it was used only to install the OS).
- I did not check it myself, but it seems that ovftool does not save snapshots.
A few more features of Ovftool, only when running on ESXI:
- Although ovftool is launched locally, the path to the host must be entered completely, along with the user and password.
- Cannot interactively read the password from the console, but requires that it be passed as a parameter on the command line.
- Only letters, numbers and `-` can be used in the password. When trying to use other characters such as `#`, the password was not accepted.
Examples of using ovftool: