Backup Strategy For Test Environment

Question

Post reply

Backup Strategy For Test Environment

oogibah

SSC Eights!

Points: 827
More actions
May 28, 2019 at 1:09 pm

#3647835

Pretty simple question this time around...

What is your backup strategy for your test environment? I'm just curious how others do it, or if they even do it at all?

Thanks!

Viewing 7 posts - 1 through 6 (of 6 total)

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

NorthernSoul SSCertifiable Points: 6869 More actions · Answer 1

I keep all non production databases in simple recovery and take a full backup each night.

Thanks

Jeff Moden SSC Guru Points: 1003861 More actions · Answer 2

I treat Dev systems exactly the same way that I treat prod systems. Being able to restore to a point in time has save a lot of lost work many times. Remember that it IS a Dev system and people are going to make mistakes that need to be undone quickly. Sometimes the Developers prepare for that and have something to undo what they've done or have run something in a transaction and can easily roll back after the see the row count (or whatever). Other times, it's truly a mistake and they need to get the data back.

--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.

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)

Beatrix Kiddo SSC-Dedicated Points: 32407 More actions · Answer 3

Our Test (and Dev) instances are supposed to be the same as Prod, and the business has quite high expectations for recoverability. In most cases (across all environments) we have a daily full backup by a 3rd party tool, and native transaction log backups at intervals of between 5 and 30 minutes depending on the system.

Regarding Dev, my view is that it's the Developers' Production environment, and we need to treat it as such where possible.

Michael L John One Orange Chip Points: 27038 More actions · Answer 4

Some dev systems are set to simple recovery, and a full backup is done nightly. These are mostly the legacy systems where little development work, if any, is being done.

Other dev systems are constantly being battered by the developers. If we were forced to go back to last nights full backup, a lot of work would be lost. These are in full recovery, with 15 minute log backups.

Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/

oogibah SSC Eights! Points: 827 More actions · Answer 5

Seems like for the most part there is a consensus on Dev should be the same as Prod... Thanks for the input guys.

Jeff Moden SSC Guru Points: 1003861 More actions · Answer 6

No problem. Thanks for the question and the feedback.

--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.

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)