Bare Metal Backup (and restore)
-
@EddieJennings Basically, this backup method it a solid 100% guaranteed method because you are capturing backups of all data in a stopped state. No worries about SQL server database states, etc. You are only backing up the backup files made by the SQL application itself.
This is a perfectly valid scenario.
Using a full image backup is dangerous if it does not talk to the database process and tell it that it is going to run a backup. Because then the Database files are not in a state to be read. This is probably what happened to your mentor/boss/whatever.
-
@EddieJennings said in Bare Metal Backup (and restore):
.... he grumbled about "problems" he's had in the past with bare metal restores, and that for our environment it's just easier to backup the data and reinstall / reconfigure servers.
If your builds are scripted or handled via state files, then this makes sense. If not, it doesn't.
-
@scottalanmiller said in Bare Metal Backup (and restore):
If everything blew up... wouldn't you install Hyper-V or VMware or whatever and THEN recover? Just because they screwed up and installed bare metal in the past doesn't mean you would recover with the same mistakes in place. You'd fix that during the restore, right?
Ideally, yes. These are three separate machines. Another project on my list is to see what would be involved in turning them into one machine with VMs.
-
@EddieJennings said in Bare Metal Backup (and restore):
@scottalanmiller said in Bare Metal Backup (and restore):
If everything blew up... wouldn't you install Hyper-V or VMware or whatever and THEN recover? Just because they screwed up and installed bare metal in the past doesn't mean you would recover with the same mistakes in place. You'd fix that during the restore, right?
Ideally, yes. These are three separate machines. Another project on my list is to see what would be involved in turning them into one machine with VMs.
Consolidation is a totally different matter. I'm just saying proper virtualization as a recovery plan. You'd never actually consider restoring to bare metal, right?
-
@scottalanmiller said in Bare Metal Backup (and restore):
@EddieJennings said in Bare Metal Backup (and restore):
@scottalanmiller said in Bare Metal Backup (and restore):
If everything blew up... wouldn't you install Hyper-V or VMware or whatever and THEN recover? Just because they screwed up and installed bare metal in the past doesn't mean you would recover with the same mistakes in place. You'd fix that during the restore, right?
Ideally, yes. These are three separate machines. Another project on my list is to see what would be involved in turning them into one machine with VMs.
Consolidation is a totally different matter. I'm just saying proper virtualization as a recovery plan. You'd never actually consider restoring to bare metal, right?
Initially, I'd think yes. However, it seems like this would be the better method (for recovery).
- Install Hyper-V on each server.
- Create a VM on each Hyper-V host that would be whatever server it was.
- Configure services, restore data.
- Get a solution that backups the VMs themselves going forward.
-
@EddieJennings said in Bare Metal Backup (and restore):
@scottalanmiller said in Bare Metal Backup (and restore):
@EddieJennings said in Bare Metal Backup (and restore):
@scottalanmiller said in Bare Metal Backup (and restore):
If everything blew up... wouldn't you install Hyper-V or VMware or whatever and THEN recover? Just because they screwed up and installed bare metal in the past doesn't mean you would recover with the same mistakes in place. You'd fix that during the restore, right?
Ideally, yes. These are three separate machines. Another project on my list is to see what would be involved in turning them into one machine with VMs.
Consolidation is a totally different matter. I'm just saying proper virtualization as a recovery plan. You'd never actually consider restoring to bare metal, right?
Initially, I'd think yes. However, it seems like this would be the better method (for recovery).
- Install Hyper-V on each server.
- Create a VM on each Hyper-V host that would be whatever server it was.
- Configure services, restore data.
- Get a solution that backups the VMs themselves going forward.
Correct. Just as you never install anything bare metal, you never restore anything bare metal.
-
@EddieJennings said in Bare Metal Backup (and restore):
- Get a solution that backups the VMs themselves going forward.
Agent based is fine too. But there are nice benefits to agentless as well.
-
@scottalanmiller said in Bare Metal Backup (and restore):
@EddieJennings said in Bare Metal Backup (and restore):
- Get a solution that backups the VMs themselves going forward.
Agent based is fine too. But there are nice benefits to agentless as well.
Agent or agentless really does not matter as long as the agentless can reach into the VM and tell SQL to shut up for a minute I need to make a snap, and then move along.
-
This post is deleted! -
@JaredBusch said in Bare Metal Backup (and restore):
@EddieJennings Basically, this backup method it a solid 100% guaranteed method because you are capturing backups of all data in a stopped state. No worries about SQL server database states, etc. You are only backing up the backup files made by the SQL application itself.
This is a perfectly valid scenario.
Using a full image backup is dangerous if it does not talk to the database process and tell it that it is going to run a backup. Because then the Database files are not in a state to be read. This is probably what happened to your mentor/boss/whatever.
True I second this, cause he is focusing on backing up files, but the downside is restoring from DR will take some time for the stuff to be ready.
Having VM export feature + his current file backup will speed the DR restore process greatly.
