January 10, 2020 at 2:15 pm
jasona.work wrote:Steve Jones - SSC Editor wrote:Good luck with that. Not sure third party tools make this better, but you're welcome to eval SQL Backup from Redgate if it might help
Yeah, I've trialed it a couple times here on my homelab (MAN I wish I could have JUST ONE test server that wasn't locked down 6 ways to Sunday at work!) and I like the interface and such.
Plus, I know it'd be easier if I had to give someone the basics to cover for me!
Maybe, someday, I'll get a REAL backup person to help out...
I heard Jeff was looking for work 🙂
BWAAAA-HAAAA!!!! Just to be sure... NOT! Like I tell the recruiters that email me, I'm currently working my dream job. I'm doing interesting work with good people for good money and a commute so short that I could ride a unicycle to work without getting chaff marks. Besides, I'm so busy that if I get any busier, I'd need to be twins. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2020 at 2:18 pm
Honestly, I thought we had pulled this from the product, but I was wrong. Here you go, object level recovery in Redgate SQL Backup.
That was my understanding, as well. Thanks for the link, Grant. I'll have a look.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2020 at 2:18 pm
Honestly, I thought we had pulled this from the product, but I was wrong. Here you go, object level recovery in Redgate SQL Backup.
ha - I hadn't even spotted that way of doing it
MVDBA
January 10, 2020 at 2:19 pm
Honestly, I thought we had pulled this from the product, but I was wrong. Here you go, object level recovery in Redgate SQL Backup.
ha , I hadn't even spotted that way of doing it
MVDBA
January 10, 2020 at 2:21 pm
Do you have any favorite links on the subject of pulling rather than pushing?
Hmmmm ...
Nah thought I had one but no luck retrieving it.
I get better luck when just dropping sql server from the search, ie., googling with the phrase: backup pull vs push.
The bottom line for me is that if your server that needs backup has privileges to "push" the backup to the remote backup server, then in the event the server needing backup gets owned, the writeable remote backup location is also at risk, whereas if the backup server "pulls" from a read only share on the backup client (like the database server containing the .bak you want saved), its less succeptible to security breeches on the database server, and since it can pull from a read only share, the client (database) server is also protected somewhat from the backup server getting taken down.
January 10, 2020 at 2:23 pm
Phil Parkin wrote:Do you have any favorite links on the subject of pulling rather than pushing?
Hmmmm ...
Nah thought I had one but no luck retrieving it.
I get better luck when just dropping sql server from the search, ie., googling with the phrase: backup pull vs push.
The bottom line for me is that if your server that needs backup has privileges to "push" the backup to the remote backup server, then in the event the server needing backup gets owned, the writeable remote backup location is also at risk, whereas if the backup server "pulls" from a read only share on the backup client (like the database server containing the .bak you want saved), its less succeptible to security breeches on the database server, and since it can pull from a read only share, the client (database) server is also protected somewhat from the backup server getting taken down.
We can "pull" the backup from a read only share, yes. Why would you not be able to do that?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 10, 2020 at 2:25 pm
Grant Fritchey wrote:Honestly, I thought we had pulled this from the product, but I was wrong. Here you go, object level recovery in Redgate SQL Backup.
ha , I hadn't even spotted that way of doing it
Yeah... there's a catch. Grant is mostly right. While it's still in the product, it's no longer supported in 2012 or later. Here's the warning...
With that in mind, you have an alternate method. If it's truly "object level" recovery that you're able to do, you should write an article on it. I think it would be one of the biggest hit articles ever on this site.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2020 at 2:36 pm
Phil Parkin wrote:Do you have any favorite links on the subject of pulling rather than pushing?
Hmmmm ...
Nah thought I had one but no luck retrieving it.
I get better luck when just dropping sql server from the search, ie., googling with the phrase: backup pull vs push.
The bottom line for me is that if your server that needs backup has privileges to "push" the backup to the remote backup server, then in the event the server needing backup gets owned, the writeable remote backup location is also at risk, whereas if the backup server "pulls" from a read only share on the backup client (like the database server containing the .bak you want saved), its less succeptible to security breeches on the database server, and since it can pull from a read only share, the client (database) server is also protected somewhat from the backup server getting taken down.
That was precisely my thought. A fellow DBA in another company recently went through a bout with a ransom-ware. The ransom-ware was able to track down where the normal backups were and nuked them. The only thing that saved him was that he shipped his backups to a remote site in a separate process not on any of the database servers or the backup system. Not having any reference on the attacked machine to the backup location(s) is a huge layer of prevention. Of course, that would also mean that I'd have to nuke the backup history and wouldn't do a thing in that area if the attack occurred during backups... and we do a shedload of log file backups not to mention that the FULL backups take hours to complete. If the attacker has access to MSDB, they could still track things so an interim "hop" for where backups are stored will probably be in order. That may be a whole lot easier to do than doing "pulls" that involve actually issuing a backup command to the remote system.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2020 at 2:43 pm
MVDBA (Mike Vessey) wrote:Grant Fritchey wrote:Honestly, I thought we had pulled this from the product, but I was wrong. Here you go, object level recovery in Redgate SQL Backup.
ha , I hadn't even spotted that way of doing it
Yeah... there's a catch. Grant is mostly right. While it's still in the product, it's no longer supported in 2012 or later. Here's the warning...
With that in mind, you have an alternate method. If it's truly "object level" recovery that you're able to do, you should write an article on it. I think it would be one of the biggest hit articles ever on this site.
Actually, get RedGate to pay you to document how to do it on their site. 😀 Negotiate residuals for every copy of the product sold.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2020 at 2:58 pm
x wrote:Phil Parkin wrote:Do you have any favorite links on the subject of pulling rather than pushing?
Hmmmm ...
Nah thought I had one but no luck retrieving it.
I get better luck when just dropping sql server from the search, ie., googling with the phrase: backup pull vs push.
The bottom line for me is that if your server that needs backup has privileges to "push" the backup to the remote backup server, then in the event the server needing backup gets owned, the writeable remote backup location is also at risk, whereas if the backup server "pulls" from a read only share on the backup client (like the database server containing the .bak you want saved), its less succeptible to security breeches on the database server, and since it can pull from a read only share, the client (database) server is also protected somewhat from the backup server getting taken down.
That was precisely my thought. A fellow DBA in another company recently went through a bout with a ransom-ware. The ransom-ware was able to track down where the normal backups were and nuked them. The only thing that saved him was that he shipped his backups to a remote site in a separate process not on any of the database servers or the backup system. Not having any reference on the attacked machine to the backup location(s) is a huge layer of prevention. Of course, that would also mean that I'd have to nuke the backup history and wouldn't do a thing in that area if the attack occurred during backups... and we do a shedload of log file backups not to mention that the FULL backups take hours to complete. If the attacker has access to MSDB, they could still track things so an interim "hop" for where backups are stored will probably be in order. That may be a whole lot easier to do than doing "pulls" that involve actually issuing a backup command to the remote system.
There's also the subject of people that have made the mistake of the service login having Domain-Admin privs, especially on legacy systems that they may have not been the ones to do the installation.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2020 at 3:08 pm
Jeff Moden wrote:x wrote:Phil Parkin wrote:Do you have any favorite links on the subject of pulling rather than pushing?
Hmmmm ...
Nah thought I had one but no luck retrieving it.
I get better luck when just dropping sql server from the search, ie., googling with the phrase: backup pull vs push.
The bottom line for me is that if your server that needs backup has privileges to "push" the backup to the remote backup server, then in the event the server needing backup gets owned, the writeable remote backup location is also at risk, whereas if the backup server "pulls" from a read only share on the backup client (like the database server containing the .bak you want saved), its less succeptible to security breeches on the database server, and since it can pull from a read only share, the client (database) server is also protected somewhat from the backup server getting taken down.
That was precisely my thought. A fellow DBA in another company recently went through a bout with a ransom-ware. The ransom-ware was able to track down where the normal backups were and nuked them. The only thing that saved him was that he shipped his backups to a remote site in a separate process not on any of the database servers or the backup system. Not having any reference on the attacked machine to the backup location(s) is a huge layer of prevention. Of course, that would also mean that I'd have to nuke the backup history and wouldn't do a thing in that area if the attack occurred during backups... and we do a shedload of log file backups not to mention that the FULL backups take hours to complete. If the attacker has access to MSDB, they could still track things so an interim "hop" for where backups are stored will probably be in order. That may be a whole lot easier to do than doing "pulls" that involve actually issuing a backup command to the remote system.
There's also the subject of people that have made the mistake of the service login having Domain-Admin privs, especially on legacy systems that they may have not been the ones to do the installation.
The worst one I've seen was the global image server having God privileges in order to push an system/disk image onto any system on the network. Goes without saying, that server got compromised by a ransomware and funny enough, the only option was a global rebuild of all the estate (thousands of systems). Me thinks that is a strong argument for doing "pulls" 😉
😎
January 10, 2020 at 3:12 pm
no more articles for me for a short while, Steve already has one that he wants me to edit, but I've been in hospital since start of December and am only just out. (influenza c, which developed into influenza a (nasty) which turned into pneumonia and a collapsed lung. - who knew you could get worse in hospital????
this is my first week back at work and I've already been driven home by my boss once this week at lunch time.
i'm taking a week off as annual leave next week and not looking at anything other than Netflix with several glasses of hot water, honey, lemon,ginger and whisky,,, with extra whisky and small naps in between.
but seriously here's how easy it is
maybe someone should write it who is capable of stringing 2 words together without having to retype the same word twice because the fingers and the keyboard are moving side to side at different speeds... besides it might be better coming from someone who has not done that journey before 🙂
MVDBA
January 10, 2020 at 3:22 pm
Jeff Moden wrote:Jeff Moden wrote:x wrote:Phil Parkin wrote:Do you have any favorite links on the subject of pulling rather than pushing?
Hmmmm ...
Nah thought I had one but no luck retrieving it.
I get better luck when just dropping sql server from the search, ie., googling with the phrase: backup pull vs push.
The bottom line for me is that if your server that needs backup has privileges to "push" the backup to the remote backup server, then in the event the server needing backup gets owned, the writeable remote backup location is also at risk, whereas if the backup server "pulls" from a read only share on the backup client (like the database server containing the .bak you want saved), its less succeptible to security breeches on the database server, and since it can pull from a read only share, the client (database) server is also protected somewhat from the backup server getting taken down.
That was precisely my thought. A fellow DBA in another company recently went through a bout with a ransom-ware. The ransom-ware was able to track down where the normal backups were and nuked them. The only thing that saved him was that he shipped his backups to a remote site in a separate process not on any of the database servers or the backup system. Not having any reference on the attacked machine to the backup location(s) is a huge layer of prevention. Of course, that would also mean that I'd have to nuke the backup history and wouldn't do a thing in that area if the attack occurred during backups... and we do a shedload of log file backups not to mention that the FULL backups take hours to complete. If the attacker has access to MSDB, they could still track things so an interim "hop" for where backups are stored will probably be in order. That may be a whole lot easier to do than doing "pulls" that involve actually issuing a backup command to the remote system.
There's also the subject of people that have made the mistake of the service login having Domain-Admin privs, especially on legacy systems that they may have not been the ones to do the installation.
The worst one I've seen was the global image server having God privileges in order to push an system/disk image onto any system on the network. Goes without saying, that server got compromised by a ransomware and funny enough, the only option was a global rebuild of all the estate (thousands of systems). Me thinks that is a strong argument for doing "pulls" 😉
😎
I have to deal with Amazon RDS (for one of our most famous clients - every single user on this site will have been in one of their stores) - let me be clear - I hate RDS and it is underpowered and under featured. - no sql mail, almost impossible to create linked servers etc etc… everything you try to do RDS won't let you
I've had to create linked servers from our on-premise sql boxes to the RDS instance and pull from a logging table about timings of certain procedures and then have our on premise server email our support team before the customer starts ringing us... I'm a 90% pull man
MVDBA
January 10, 2020 at 3:34 pm
no more articles for me for a short while, Steve already has one that he wants me to edit, but I've been in hospital since start of December and am only just out. (influenza c, which developed into influenza a (nasty) which turned into pneumonia and a collapsed lung. - who knew you could get worse in hospital????
Damn! I've never had a collapsed lung but know other people that have. It's definitely NOT a cake walk. Glad it turned out ok in the end. Were they able to do a full restoration of the collapsed lung?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2020 at 3:35 pm
Ooooo... interesting and very timely subject for me, Patrick. Do you have any favorite links on the subject of pulling rather than pushing?
I'll have to look. It's more a a Windows issue. If you log into a host (RDP) and start copying, the SMB copy starts to take up memory on the remote host, so there is some contention for SQL Server. Better to log into the destination host and "pull" the copy from the SQL instance host, which doesn't use the same memory. Not sure why. I know Brent Ozar presented on it and showed the memory dip, and someone at MS talked about this at one of the MVP Summits.
I'll ping Brent.
Viewing 15 posts - 64,336 through 64,350 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply