WavebreakmediaMicro - Fotolia
Although backup and recovery planning often focuses on protecting production settings, administrators are sometimes tasked with protecting testing and development (test/dev) environments.
Some organizations have a team of software developers who write custom applications either to sell or for the organization's internal use. Similarly, the administrative staff may operate a virtual lab that mimics the production network but is used for testing purposes.
In either case, protecting these test/dev environments can pose special challenges.
The biggest challenge with backing up a virtual lab is isolation. Virtual labs are sandboxed to not interfere with production. Administrators may have to adopt separate backup infrastructure dedicated to the sandboxed environment. However, these scenarios do not handle user workloads or production data, so a lightweight option may be sufficient.
Protecting software development may be a much bigger challenge. Software development environments are highly dynamic and therefore require frequent backups. Furthermore, they require administrators to back up nonstandard applications (such as programming tools or newly developed applications). The development staff must also maintain strict version tracking and be able to revert to a previous build version whenever necessary.
These challenges mean that development and testing environments cannot be backed up in the same way as run-of-the-mill infrastructure servers or application servers. There are a number of considerations that must be taken into account.
Where does the data reside?
The first question that must be addressed is the physical location of the data that needs to be protected.
In modern dev/test environments, newly written code is typically stored on a network server so that the code can be shared among the development team.
However, there may be other elements in other locations that also need to be protected. For example, there might be sample data, development libraries or special tools that reside on the developer's PCs or in a network share.
It is important for the backup administrator to understand exactly what needs to be protected and where the protected resources reside.
What databases need to be protected?
Developers are increasingly relying on collaborative development that allows code to be shared among multiple developers. These test/dev environments are often database-driven. One example is Microsoft Team Foundation Server, which allows for code management, project management and software version control for developers.
In smaller deployments, Team Foundation Server uses a SQL Server instance to store a configuration database, a warehouse database and a collection name database. In larger environments, however, there can be additional databases and multiple database servers. For instance, there may be databases related to analysis and reporting, and there may be databases that contain working data sets.
As an administrator, you must communicate with the development staff to determine what databases are in use, what versions of SQL Server are being used, who is responsible for maintaining those servers and how large the databases could potentially become.
From a backup standpoint, protecting a collection of databases for the development staff isn't that different from protecting any other database-driven application.
However, there are exceptions. For example, outdated database servers can be difficult to protect using modern backup software.
You also must check for any established data protection best practices specific to the development tools being used. For example, it is common for backup applications to ignore temp files, but certain types of temp files can be important in some development environments.
Developers typically have very strict policies and procedures for maintaining version control over the code that they write. A backup administrator must make sure that backups are completed in a way that captures each new software build while allowing the development team to revert to a previous version if necessary. In some cases, version control is a function of the development database; but in other environments, version control is a manual function.
In these examples, you cannot assume that the organization's standard retention policies will be appropriate for the development and testing environment.
Perhaps the most important part of protecting a test/dev environment is establishing an ongoing dialogue with those who use what you are protecting.
Dev/test environments are highly dynamic and subject to frequent change. If resources are created or moved, then the development team must communicate those changes to the administrative staff to properly protect those resources.
Server colocation in testing and development