Here are a few of the things I do for local development.
First off I have local DNS either in my local DNS server (harder) or in my host file. In either case it does NOT match production, but I have both in the host alias. For example I have www.twincitytc.org (public) and twincitytc.home.crewstone.com (local). That allows me to move a backup of the site (along with the DB) to my local machine(s) and run it pretty much as is.
I will take a template of the production site (not a backup) and change that to a template embedded in an install ZIP for the version of DNN I'm using. You'll need to have all the same skins, module installs, etc, in that same ZIP. Then you unzip that to a fresh directory and you have a brand new site once you run through the installation. The advantage of doing this is you can take the local install, and repeat the process going back to production. The disadvantage is this doesn't work for modules that don't support import/export. The big advantage is if you have older sites that have been upgraded several times this is a great way to create a "clean" install, but you will need a separate process to refresh the registered users.
Now the other thing that's important to do is PRACTICE. Once your site reaches a certain side moving the whole thing back and forth is impractical. To have a copy that looks like production, make your changes, test them local, them REPEAT that process in production. For example I'll have modules I'll develop locally, test them locally, then I create an module installer and test it on a COPY of production, then I install it on production. May sounds like a lot of work, but it you're working on multiple sites you will need a process to validate, and to document what you changed (and back it out if it doesn't work).