SQL Server Backup Design
-
@jaredbusch said in SQL Server Backup Design:
@eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.
Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.
Everything else can be rebuilt. It may take more time, but with that
.bakfile I can bring the business back to life.That makes perfect sense. Especially considering "what happens if Veeam gets hosed?" As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?
-
@eddiejennings said in SQL Server Backup Design:
@jaredbusch said in SQL Server Backup Design:
@eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.
Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.
Everything else can be rebuilt. It may take more time, but with that
.bakfile I can bring the business back to life.That makes perfect sense. Especially considering "what happens if Veeam gets hosed?"
As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?Bah. I know the answer to that. It would be dumb to just have those files only in one place, so of course you'd have it local. Ok, time to go home and take a nap. My brain's being dumb.
-
@eddiejennings said in SQL Server Backup Design:
@eddiejennings said in SQL Server Backup Design:
@jaredbusch said in SQL Server Backup Design:
@eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.
Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.
Everything else can be rebuilt. It may take more time, but with that
.bakfile I can bring the business back to life.That makes perfect sense. Especially considering "what happens if Veeam gets hosed?"
As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?Bah. I know the answer to that. It would be dumb to just have those files only in one place, so of course you'd have it local. Ok, time to go home and take a nap. My brain's being dumb.
I wouldn't say it is dumb at all. You should already have a copy inside Veeam, so that's one, plus the live data, plus the place where you put the copy. Who knows, you might not have enough open storage on the local disk to make a copy there.. just a though.
-
I'm with Jared on this one...
Backing up through the application layer (SQL) as often as you can depending on change frequency. For example, every 15 minutes.
Hourly and daily through the SQL backup tools.
At least daily full VM backup at the hypervisor level.
I prefer backups that use a standard file format, so you don't have to rely on Veeam for example to restore it. Veeam has screwed up too many times for me to want to rely on it like that.
-
DILLY DILLY!!! .bak
I also use the maintenance plans, super easy. -
@eddiejennings said in SQL Server Backup Design:
@jaredbusch said in SQL Server Backup Design:
@eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.
Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.
Everything else can be rebuilt. It may take more time, but with that
.bakfile I can bring the business back to life.That makes perfect sense. Especially considering "what happens if Veeam gets hosed?" As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?
Basically yes.
-
@tim_g said in SQL Server Backup Design:
I'm with Jared on this one...
Backing up through the application layer (SQL) as often as you can depending on change frequency. For example, every 15 minutes.
Hourly and daily through the SQL backup tools.
At least daily full VM backup at the hypervisor level.
I prefer backups that use a standard file format, so you don't have to rely on Veeam for example to restore it. Veeam has screwed up too many times for me to want to rely on it like that.
I have never had been fail
-
@jaredbusch said in SQL Server Backup Design:
@tim_g said in SQL Server Backup Design:
I'm with Jared on this one...
Backing up through the application layer (SQL) as often as you can depending on change frequency. For example, every 15 minutes.
Hourly and daily through the SQL backup tools.
At least daily full VM backup at the hypervisor level.
I prefer backups that use a standard file format, so you don't have to rely on Veeam for example to restore it. Veeam has screwed up too many times for me to want to rely on it like that.
I have never had been fail
Except for statements like this.
-
@eddiejennings said in SQL Server Backup Design:
@eddiejennings said in SQL Server Backup Design:
@jaredbusch said in SQL Server Backup Design:
@eddiejennings I use Veeam and still use the built in SQL backup tools and save the backup to another device because that data is absolutely fucking critical.
Worst case scenario Veeam is hosed and you cannot restore the VM properly. You still have SQL backup file.
Everything else can be rebuilt. It may take more time, but with that
.bakfile I can bring the business back to life.That makes perfect sense. Especially considering "what happens if Veeam gets hosed?"
As far as the backup tools, do you save that data to SQL Server's local storage, and then have some kind of task run that makes a copy of it to another device?Bah. I know the answer to that. It would be dumb to just have those files only in one place, so of course you'd have it local. Ok, time to go home and take a nap. My brain's being dumb.
I use something like crash plan pro on another computer and a hard link to the SQL back up file directory to back it up offsite
-
@scottalanmiller said in SQL Server Backup Design:
@jaredbusch said in SQL Server Backup Design:
@tim_g said in SQL Server Backup Design:
I'm with Jared on this one...
Backing up through the application layer (SQL) as often as you can depending on change frequency. For example, every 15 minutes.
Hourly and daily through the SQL backup tools.
At least daily full VM backup at the hypervisor level.
I prefer backups that use a standard file format, so you don't have to rely on Veeam for example to restore it. Veeam has screwed up too many times for me to want to rely on it like that.
I have never had been fail
Except for statements like this.
For some reason Siri does not like Veeam yet. Even though correct it a lot
