MVDBA (Mike Vessey) wrote:
Eirikur Eiriksson wrote:
Jeff Moden wrote:
Jeff Moden wrote:
Phil Parkin wrote:
Do you have any favorite links on the subject of pulling rather than pushing?
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
I'm not the greatest fan of RDS either, think of it as less than the equivalent of SQL Server Express in terms of usability.
In few recent migration projects I ended up using EC2 instances as RDS just did not cut it.