Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Manual or third-party ESX(i) backup?



I do mean human (or scripted).    If you run VMWare on a workstation,
and you preserve the VM folder for each VM, you can easily restore
what you have.

Does the same hold true, in theory, for the server side?

On Sat, Nov 1, 2014 at 9:59 AM, Edward Ned Harvey (blu)
<blu at nedharvey.com> wrote:
>> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
>> bounces+blu=nedharvey.com at blu.org] On Behalf Of Scott Ehrlich
>>
>> From a fundamental viewpoint, what is the difference between manually
>> copying VMs from  the server to the backup system and using a
>> commercial product, being SRM or third-party?
>
> What are you calling "manual?"  I normally think "manual" means involving human interaction, which would obviously not be ok for backups.
>
> Do you mean "home grown?"  If the question is home grown vs commercial 3rd party backup solution, then I can say this:  Depending on what you use for underlying storage, it can be easy to do good backups and be guaranteed backup integrity without any data loss of any sort - but the big difficulty is in detection & reporting of error conditions.  I wrote scripts to "zfs send" from our primary storage to offsite storage, and to removable media that obviously must be manually rotated.  The zfs send itself was so easy as to be nearly trivial.  (A matter of minutes to get it right).  I had to put a couple of days of effort into making sure we would detect & report failures if they occur.  And they have occurred - due to a hardware problem on the recipient system, due to insufficient capacity on the recipient system, due to temporary overwhelming quantity of data to send for a few days, and due to network unreliability.  And I think those have been all the causes for problems so far, but the above have all occurred at least once, and knock on wood, so far have always been correctly reported.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org