Setting up a Staging Server
The most important thing is to replicate the live environment. The staging server should diverge from the live server only in the ways you want to test. This ensures that when you apply the change to the live server, no hidden differences come out to bite you.
The simplest backup would involve a copy of the File System and a Database export. Commonly used for this purpose are two common Unix utilities, tar/gzip and mysqldump. Tar/Gzip allows you to group a collection of files and folders into one file, and then gzip can compress the file for faster download and easier storage. Mysqldump allows you to export your database as a collection of SQL statements. These statements can be used to recreate the database for your staging server. Once you have the Staging Server set up you can test changes in relative safety.
Other considerations regarding a staging server
It is helpful to use version control along with the staging server. Proper use of version control can ease some of the pains associated with keeping track of the various changes that have been made.
Similarly, the ability to reset a staging server to the live version at the push of a button can be useful future to have. Version control will often provide this future, another good reason to use it.
Finally it is important to understand what changes are actually saved in the Database versus those that are saved as a file. Complex online systems often save changes that you make somewhere in the database. It is possible but slightly harder to migrate these types of changes. A plan should be implemented, before starting work, concerning the method that will be used to track and export these changes.
Let us know if you find this helpful and if you have any questions.