My Server Crash Writeup 11-10-2015
-
75min from 100GB? Sounds like your disk arrays are a bit slow.
-
@Jason said:
75min from 100GB? Sounds like your disk arrays are a bit slow.
That's over the LAN. Might have been a bit less time and a bit more GB.
-
-
I had to do the math... the best expectation to be around 17 mins for 100 GB, So yea 75 seem a bit long.. but that depends one whatever else you have happening on either of the disk arrays.
-
Sorry it was 126GB.
And it might have only been 60 minutes. I didn't time it because I hightailed out of there to get to a Wawa for a hoagie. Then a second Wawa when the first was closed for some inexplicable reason.
It's not an array. It's from the Datto to the new server, in the BMR environment.
-
BTW: things are ridiculously fast on this new temporary machine.
It's just an i3 or an i5, but I think the SSD is what is making it fast.
Server 2003 never had it so good!
-
@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.
