Are the posted questions getting worse?

  • Jeff Moden

    SSC Guru

    Points: 995608

    MVDBA (Mike Vessey) wrote:

    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


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden

    SSC Guru

    Points: 995608

    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.

    That was my understanding, as well.  Thanks for the link, Grant.  I'll have a look.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21453

    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

    MVDBA

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21453

    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

    MVDBA

  • x

    SSC-Insane

    Points: 23533

    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.

     

  • Grant Fritchey

    SSC Guru

    Points: 396209

    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.

    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

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • Jeff Moden

    SSC Guru

    Points: 995608

    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.

     

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden

    SSC Guru

    Points: 995608

    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.

     

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden

    SSC Guru

    Points: 995608

    Jeff Moden wrote:

    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


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden

    SSC Guru

    Points: 995608

    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.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Eirikur Eiriksson

    SSC Guru

    Points: 182409

    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" 😉

    😎

     

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21453

    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

    1. open sql compare
    2. set your backup and your target database to compare
    3. compare
    4. compare
    5. compare2
    6. generate a  script (I compared to last backup 3 days ago and we haven't changed anything or dropped a proc, but you can see the principle

    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

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21453

    Eirikur Eiriksson wrote:

    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

  • Jeff Moden

    SSC Guru

    Points: 995608

    MVDBA (Mike Vessey) wrote:

    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


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 717406

    Jeff Moden wrote:

    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 64,501 total)

You must be logged in to reply to this topic. Login to reply