Post reply

Backup Compression

  • January 4, 2012 at 8:58 pm

    #250848

    Comments posted to this topic are about the item Backup Compression

    Thanks

  • January 4, 2012 at 8:59 pm

    #1428783

    Nice question

    If everything seems to be going well, you have obviously overlooked something.

    Ron

    Please help us, help you -before posting a question please read[/url]
    Before posting a performance problem please read[/url]

  • January 4, 2012 at 10:11 pm

    #1428790

    That's two wrong in a row for me 🙁

    Paul White
    All articles available on SQL.kiwi
    @SQL_Kiwi

  • January 5, 2012 at 2:02 am

    This was removed by the editor as SPAM

  • January 5, 2012 at 2:09 am

    #1428834

    First attempt this year, and was lucky 🙂

    Good question ... thanks.

    Kwex.

  • January 5, 2012 at 5:34 am

    #1428933

    Thanks for the easy and straightforward question. Sometimes not having to think hard first thing in the morning is great.

    And then I started thinking ... but WHY can't they co-exist? Is it a design choice, or is there a physical limitation that prevents this from being implementable?

    [font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
    Connect to me on LinkedIn

  • January 5, 2012 at 5:40 am

    #1428936

    Went with my gut and got it right. Thanks for the question.

    http://brittcluff.blogspot.com/

  • January 5, 2012 at 5:55 am

    #1428944

    Good question, thanks.

    M&M

  • January 5, 2012 at 6:03 am

    #1428947

    Hi,

    More information about the restriction can be found at the below link;

    http://support.microsoft.com/kb/2297053

  • January 5, 2012 at 6:05 am

    #1428948

    Thomas Abraham (1/5/2012)

    Thanks for the easy and straightforward question. Sometimes not having to think hard first thing in the morning is great.

    And then I started thinking ... but WHY can't they co-exist? Is it a design choice, or is there a physical limitation that prevents this from being implementable?

    Hi ,

    You can find more information at the below link;

    http://support.microsoft.com/kb/2297053

  • January 5, 2012 at 6:40 am

    #1428971

    arun1_m1 (1/5/2012)

    Thomas Abraham (1/5/2012)

    Thanks for the easy and straightforward question. Sometimes not having to think hard first thing in the morning is great.

    And then I started thinking ... but WHY can't they co-exist? Is it a design choice, or is there a physical limitation that prevents this from being implementable?

    Hi ,

    You can find more information at the below link;

    http://support.microsoft.com/kb/2297053%5B/quote%5D

    Thanks for the link. However, I don't think it explains the underlying reason that this must be the case. It explains the results of attempting to add a backup in the different permutations, but it doesn't explain WHY that MUST be the way it works. What is there about mixing a compressed and uncompressed backup in the same media set that is either impossible or undesirable to implement?

    [font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
    Connect to me on LinkedIn

  • January 5, 2012 at 7:22 am

    #1428995

    Exactly. I agree that this limitation really makes no sense. There's no reason why two backups can't go to the same file, one compressed, one not compressed, and that link merely explains how and not why.

  • January 5, 2012 at 7:26 am

    #1429002

    Gut said one way, but never tried it the way the third option said. Went with gut and got it right.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • January 5, 2012 at 7:31 am

    #1429008

    I happened to have been researching this just a few months ago since we have started to go with compressed backups for the servers that support it. Nice question.

  • January 5, 2012 at 9:08 am

    #1429094

    Thomas Abraham (1/5/2012)

    arun1_m1 (1/5/2012)

    Thomas Abraham (1/5/2012)

    Thanks for the easy and straightforward question. Sometimes not having to think hard first thing in the morning is great.

    And then I started thinking ... but WHY can't they co-exist? Is it a design choice, or is there a physical limitation that prevents this from being implementable?

    Hi ,

    You can find more information at the below link;

    http://support.microsoft.com/kb/2297053%5B/quote%5D

    Thanks for the link. However, I don't think it explains the underlying reason that this must be the case. ...

    But it does answer at least part of your question. As the article states, the compression setting is stored in (and hence read from) the header of the media set. That, at least, was clearly a design choice on Microsoft's part. Why they made that choice is anyone's guess.

    My guess is that it was inherited from tape systems, as the compression option for tape was historically implemented in firmware because back in the day general purpose CPUs weren't fast enough or were too busy doing other tasks to compress the data as well.

Viewing 15 posts - 1 through 15 (of 30 total)

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