My Server Crash Writeup 11-10-2015
-
@BRRABill said:
If I had the VHDX, then hardware would be totally out of the equation. I would think if I back up the VM itself as a server, it needs to be restored as such.
Yes, but then the software that hosts it is required for a restore.
-
@BRRABill said:
@scottalanmiller said:
Those discussions have been 100% about why imaging as a process is not generally appropriate for workstations. In every case it has been pointed out that for servers it is standard and generally very good to be able to do. No amount of it being a poor technology choice for desktops would imply that it is bad for servers.
I meant that in that sometimes it is a chore to get the BMR working, and sometimes it doesn't at all.
The "store the data separately" concept.
Obviously that wouldn't work for database servers, etc..
Actually for database servers it would be even that much more important to backup the data separately.
-
@BRRABill said:
@scottalanmiller said:
Every server should be virtualized 100% of the time. That includes the disaster recovery. Any use of a physical server is negative.
For DR ... how do you back up the VM? The actual machine itself? Or the VHDX file?
Those are one and the same.
-
@scottalanmiller said:
Those are one and the same.
I guess VM backups have me confused, then.
I thought you could either backup the VHD files through the Hyper-V server itself, or the VM through the Vm (as a client on the VM).
-
@BRRABill said:
@scottalanmiller said:
Those are one and the same.
I guess VM backups have me confused, then.
I thought you could either backup the VHD files through the Hyper-V server itself, or the VM through the Vm (as a client on the VM).
That is not a backup. That is copying the HDD.
There is other metadata involved in a VM. A proper backup gets this data also.
-
@BRRABill said:
@scottalanmiller said:
Those are one and the same.
I guess VM backups have me confused, then.
I thought you could either backup the VHD files through the Hyper-V server itself, or the VM through the Vm (as a client on the VM).
I feel like you are trying to delve under the hood and are attempting to talk mechanisms, not that that is wrong, but it is leading you astray. There are hypervisor level backups taking in conjunction with the platform handling the backup and traditional host backups taken from an agent inside of the OS (there are actually agents in both cases, often they are OS components making it less clear and hypervisor ones are called agentless and OS ones refer to agents.)
Yes you could shut down the hypervisor, take a copy of a VHD and then recover (with some manual intervention to Jared's point) but it is not how any tool works and not what anyone means when they are talking about these systems. Stick with the concepts of a platform level backup (images taken agentlessly) and host level backup (agents inside the OS, works on physical systems, too.)
-
@scottalanmiller said:
Stick with the concepts of a platform level backup (images taken agentlessly) and host level backup (agents inside the OS, works on physical systems, too.)
I think I get it, then.
Which method do most SOHO/SMB use, or it entirely driven by circumstance?
-
@BRRABill said:
Which method do most SOHO/SMB use, or it entirely driven by circumstance?
Size of the organization is not a factor other than the smallest firms get backup for free from Unitrends and Veeam for platform backups, so most only look at that. Once paying for it, they tend to evaluate more or less equally.
-
The one big difference is that snowflake firms (or any size) tend to lean towards platform-based, agentless backups while DevOps firms almost never take platform-based backups because they have no need to ever restore a full VM, only the data.
