When developing, make a copy of Production and develop against that db copy. For large critical installs have another copy of Production to test the "release" of your development work to this test copy then if this tests OK then you can better guarantee the release to Production.
Be careful that emails don't fire from the Development database when you take a copy - ie break the email settings or point them to an smtp server that can collect all the outgoing emails into a single mailbox for testing email rules.
Also becareful with Codes and enure that codes only ever get made in one side and get ACED between them as there are UIDs and so if these get stuffed up then the Business rules etc that might use them in criteria can be stuffed up also.
I can confidently say that for v4.5 - yes a normal SQL backup contains both data and configuration (forms, business rules, etc - everything in the System Console) and so is good for DR.
You would of course need (written down) the details required to rebuild the connection between the App server and the DR Database server - ie. everything in the Server Settings Editor.
I'm pretty sure that SD5 still has a single SQL database that contains data and config. You could look - unless the naming standard has changed the tables with ITSM_ are generally data and REP_ are generally config. But the exact separation isn't quite that simple?
Oh yes and you will also need to ensure the FTP site that stores the attachments is backed up. I assume that if the FTP site is specified in the Attachment Settings is done via a DNS entry rather than using the machine name, moving the FTP location (eg in a DR situation) would be easier.
I have just realised that we have used the App server name - damn.