My Server Crash Writeup 11-10-2015
-
@BRRABill said:
*ML3: There has been a lot of discussion about BMR and why it's not always a great idea.
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.
-
@BRRABill said:
It's just an i3 or an i5, but I think the SSD is what is making it fast.
Storage is normally nearly the entire bottleneck in SMB systems.
-
@scottalanmiller said:
@BRRABill said:
*ML3: There has been a lot of discussion about BMR and why it's not always a great idea.
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.
do you mean that restoring bare metal servers with system images is not generally appropriate ???
(sorry sometimes your english american guys looks confusing to me, i think it is slang not academic, right)
-
@IT-ADMIN said:
@scottalanmiller said:
@BRRABill said:
*ML3: There has been a lot of discussion about BMR and why it's not always a great idea.
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.
do you mean that restoring bare metal servers with system images is not generally appropriate ???
(sorry sometimes your english american guys looks confusing to me, i think it is slang not academic, right)
No slang, no sarcasm. Imaging is good for servers and virtualized workstations, imaging is generally bad for physical workstations.
-
now i understand you, thank you
and sorry for my poor english, sometimes i want to make sure whether i understand your idea or not, for this reason i ask a question after an answer
-
so virtualization is the safest solution for disaster recovery
-
@IT-ADMIN said:
so virtualization is the safest solution for disaster recovery
Every server should be virtualized 100% of the time. That includes the disaster recovery. Any use of a physical server is negative.
(Yes there are super rare exceptions, no they don't apply to anyone wondering if it applies to them.)
-
@scottalanmiller unless it applies, then it applies. if it doesn't, it wont. ok?
-
@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..
-
@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?
-
@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?
You use something like Veeam to backup your VMs to whatever Backup storage you have.
Veeam takes care of the whole thing, you don't worry about the VHDX. -
@Dashrender said:
You use something like Veeam to backup your VMs to whatever Backup storage you have.
Veeam takes care of the whole thing, you don't worry about the VHDX.My question, I guess, is....
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.
But I will admit to being unfamiliar with the backup of VMs, having on physical servers as the current juncture. (Soon to change though, hence the questions.
) -
@BRRABill said:
For DR ... how do you back up the VM? The actual machine itself? Or the VHDX file?
Generally no. You can use Snapshots but, most of them also support using a client which is far more powerful. You basically get a SysPrep'ed image that boots to WinPE like this. Meaning teoortecially you could switch from Hyper-V to Vmware if you needed to (or vice-versa) on a backup (or even to a physical box if the whole virtual system went crazy). With snapshots you're locked in.
-
@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?
