Data recovery from system or application crashes

  • Hi,

    Can anyone please let me know what are the steps to recover the database after system is crashed? I would really appreciate it. I am a junior DBA with not a lot of experience started as intern.

    Thanks in advance

  • sneaulal (6/16/2016)


    Hi,

    Can anyone please let me know what are the steps to recover the database after system is crashed? I would really appreciate it. I am a junior DBA with not a lot of experience started as intern.

    Thanks in advance

    That is really dependent on your system SLAs, Recovery Point Objectives, and Recovery Time Objects. Your best bet is to start with your Senior DBA and/or manager to determine the Standard Operating Procedures for your organization. They may different for different classes of databases and/or applications and can also vary from organization to organization.

    Can also depend on the type of failure encountered. Each situation can be unique.

  • Lynn Pettis (6/16/2016)


    sneaulal (6/16/2016)


    Hi,

    Can anyone please let me know what are the steps to recover the database after system is crashed? I would really appreciate it. I am a junior DBA with not a lot of experience started as intern.

    Thanks in advance

    That is really dependent on your system SLAs, Recovery Point Objectives, and Recovery Time Objects. Your best bet is to start with your Senior DBA and/or manager to determine the Standard Operating Procedures for your organization. They may different for different classes of databases and/or applications and can also vary from organization to organization.

    Can also depend on the type of failure encountered. Each situation can be unique.

    Also check with your supervisor for the recovery documentation. If your business doesn't have recovery documentation, then you should take the initiative to create it as soon as you have a breather from your current crisis (writing down things as you go along, so you remember what worked and what didn't, would also be a good idea. It's hard post-crisis to go back and remember exactly what worked when you're trying so many things).

    We're assuming of course that this question actually came from a current crisis. If you're just asking the question for knowledge's sake (just in case kind of thing), please let us know and we'll be happy to point you to documentation you can use to study from. But, as Lynn said, it's hard to answer the question in a generic way because each business has its own unique setup and challenges.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • The two most important things are to start running SQL Server backups of all your databases and, test those backups by occasionally running a restore (to a test system, or dev, or something, not your production system).

    There are a whole slew of other methods and mechanisms that the others have started to outline. All of it's applicable. However, you really need to start with backups. Here's an article to get you started.[/url]

    Are you currently in an emergency situation?

    "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

  • Thank you so much for all of your help ! I really appreciate it. I don't have any emergency yet but just want to be prepared in case it happens.

  • Thank you so much for your help ! I really appreciate it. I don't have any emergency yet but just want to be prepared in case it happens.

  • Thank you so much for your help ! I really appreciate it. I don't have any emergency yet but just want to be prepared in case it happens.

  • So, for just in case... Follow these steps.

    1) Contact your users and find out the maximum and minimum amounts of data loss (1 hour, 1 day, etc.) the business can tolerate if Sharknado hits the office and destroys EVERYTHING. Make sure their answers are realistic and double-check them with your boss and the big boss.

    2) While waiting for these answers, check what the current recovery plan is.

    3) Check what the current backup plan is.

    4) Verify the backup plan fits what the recovery plan is. If there is no recovery plan, then create a recovery plan based on the business needs / data loss tolerance discovered in step 1.

    5) Create a new backup plan / adjust the current backup plan to meet the needs of the recovery plan. DO NOT force the recovery plan to fit the backup plan. It will end badly if you reverse the steps.

    6) Setup a backup testing plan (which means restoring your backups at regular intervals to ensure they are restorable) and a backup storage plan (offsite storage, retention time frames, etc.).

    7) Write up a DR plan (which includes the recovery plan, but is not only your recovery plan).

    8) Get user / tech team buy-in on all plans. <--- This is VERY important.

    9) Test the DR plan with all involved parties during off hours.

    10) Get a raise because u dun gud. (Okay, I can't guarantee this step, but it's more than likely if something isn't already set up).

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • Brandie Tarvin (6/17/2016)


    So, for just in case... Follow these steps.

    1) Contact your users and find out the maximum and minimum amounts of data loss (1 hour, 1 day, etc.) the business can tolerate if Sharknado hits the office and destroys EVERYTHING. Make sure their answers are realistic and double-check them with your boss and the big boss.

    2) While waiting for these answers, check what the current recovery plan is.

    3) Check what the current backup plan is.

    4) Verify the backup plan fits what the recovery plan is. If there is no recovery plan, then create a recovery plan based on the business needs / data loss tolerance discovered in step 1.

    5) Create a new backup plan / adjust the current backup plan to meet the needs of the recovery plan. DO NOT force the recovery plan to fit the backup plan. It will end badly if you reverse the steps.

    6) Setup a backup testing plan (which means restoring your backups at regular intervals to ensure they are restorable) and a backup storage plan (offsite storage, retention time frames, etc.).

    7) Write up a DR plan (which includes the recovery plan, but is not only your recovery plan).

    8) Get user / tech team buy-in on all plans. <--- This is VERY important.

    9) Test the DR plan with all involved parties during off hours.

    10) Get a raise because u dun gud. (Okay, I can't guarantee this step, but it's more than likely if something isn't already set up).

    And remember one thing, office politics may throw an monkey into this so make sure you have support up the chain before going forward. If you can't get support your efforts may be for naught.

  • Lynn Pettis (6/17/2016)


    Brandie Tarvin (6/17/2016)


    So, for just in case... Follow these steps.

    1) Contact your users and find out the maximum and minimum amounts of data loss (1 hour, 1 day, etc.) the business can tolerate if Sharknado hits the office and destroys EVERYTHING. Make sure their answers are realistic and double-check them with your boss and the big boss.

    2) While waiting for these answers, check what the current recovery plan is.

    3) Check what the current backup plan is.

    4) Verify the backup plan fits what the recovery plan is. If there is no recovery plan, then create a recovery plan based on the business needs / data loss tolerance discovered in step 1.

    5) Create a new backup plan / adjust the current backup plan to meet the needs of the recovery plan. DO NOT force the recovery plan to fit the backup plan. It will end badly if you reverse the steps.

    6) Setup a backup testing plan (which means restoring your backups at regular intervals to ensure they are restorable) and a backup storage plan (offsite storage, retention time frames, etc.).

    7) Write up a DR plan (which includes the recovery plan, but is not only your recovery plan).

    8) Get user / tech team buy-in on all plans. <--- This is VERY important.

    9) Test the DR plan with all involved parties during off hours.

    10) Get a raise because u dun gud. (Okay, I can't guarantee this step, but it's more than likely if something isn't already set up).

    And remember one thing, office politics may throw an monkey into this so make sure you have support up the chain before going forward. If you can't get support your efforts may be for naught.

    Excellent point.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

Viewing 10 posts - 1 through 9 (of 9 total)

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