You are not logged in.
Pages: 1
Hello,
thank you, and I got the black Friday discount per mail
However, this should be a simple solution without much configuration or features (oneDiff, etc). It has to be robust and secure in our environment (thus alas, no NFS).
2 of the to backup VMs will be on the other "fast" R10 datastore, the 2 remaining VMs (in total ~200GB) will be backed up to the same R5 datastore .
BTW it's a HP DL360 G6 with 4xSAS R10 and 4x SATA R5
Dear forum,
I have a ESXi 6.0 Server with two datastores, both used for VMs.
I'm in a network used by other companies (+network infrastructure is out of my control) so I don't want to use NFS (krb5p is not supported yet, not even by esxi 6.5). I looked into ssh tunneling NFS but there seem to be some pitfalls (locking, localhost forward) and performance issues.
I also don't want to use rsync because I would need to give away root access to the backup server (login with public/private key). Also network outages could leave my VMs with unused snapshots which I would need to consolidate afterwards.
So my plan is to:
1) backup to a subfolder on the local datastore (Raid 5) where some VMs are running
2) have a constant sshfs connection from the backup server to the datastore-subfolder and copy the backed-up VMs to the backup server via a cronjob at the backup server.
3) limit backup amount with backup-room so I don't fill up the datastore
Beside the increased disk write use during backup (only once weekly, it's disaster backup; file-based backup is done differently), is there something gravely speaking against it?
To put it in perspective: it's a total of 4 VMs to back up (2x Windows, 2x Linux, in total not quite 400GB). Probably I need to add another VM sometime next year
Pages: 1