Reasons to Backup (or not backup) QA and Dev Databases Pretty simple question: is it standard/best practice to backup dev and QA instances of the database?

Assume that the schema information is kept in some form of source control.
QA and dev databases (I will refer to these as non-prod[uction] to encompass all life cycles) are still databases.  So the business (in this case, might be the app dev team) needs to determine what type of disaster recovery they require.

In my opinion, SLAs don't just apply to production databases.  They apply to any data store that requires a certain RPO/RTO.  In the case of development databases, DML might not be a huge concern, but the loss of DDL could be application-breaking.

The point I'm trying to get at, is we here can't answers whether or not you'll want to back up your non-prod databases.  You will need to find out what type of disaster recovery is required of these databases.  There's a chance that database creation scripts generated weekly is enough.  But there's also a possibility they may require native database backups.

Personally, I always resort to some form of backups.  Even if it's simple recovery and just daily full backups.  These non-prod databases are typically not gigantic (although there are definitely exceptions to that rule), and end-user impact isn't usually a big concern in lower lifecycle environments (again, there are exceptions here as well).  I typically err on the side of more DR than less DR.  But I'd still recommend talking to the business group to get clearly defined and documented guidance for disaster recovery.  You don't want to be the reason that a week of development was just lost because you haven't been taking backups.