I suspect there are others, but I don't know what they all are. Some of these have a mv or cp operation, or can be simulated by exporting to an XML (or binary) file, and then reloading it, but many of them cannot. That means Windows has many one-way operations, where if you do them (and wrong), there is no simple on-line recourse.
This is surprising to Unix users: Most Unix programs use the Unix filesystem directly, and so all the tools that are used to operate on files are the same tools for operating on most programs. As a result, most programs don't need to, (nor do they) offer individual and separate back-up procedures or configuration interfaces. As an example, even the most invasive changes to a large configuration file are simply a matter of copying the file to a safe place, making the change, and copying it back if there was a problem.
Go slow. Always test the entire process ahead of time on a separate clone of your network. That means for every windows server, you need a clone on a separate (isolated) network that is otherwise configured the same way.
A successful Windows administrator will be able to use these methods in conjunction with other diagnostic methods. This document simply attempts to outline how to set yourself up to safely perform configuration changes in a recoverable way. It doesn't make any attempt to describe what those configuration changes might be.
Active Directory is essentially an LDAP store that is "discovered" via DNS, and a kerberos server that stores information in LDAP.
You can use regular LDAP tools, but only to query the database. You cannot meaningfully use them to backup and restore any information.
There is no reliable backup or restore feature for Active Directory, however Cloning and active directory is very easy:
Windows caches login information, so always keep an extra user handy that you only use for this purpose.
At this point you can make the desired changes to Active Directory. In order to "recover", simply shut down your original domain controller and "seize" the roles on the clone. Then attach the clone and it is now the new Domain Controller. Destroy the original domain controller. Do not ever attach it to the network again..
It is helpful to have two domain controllers, which means that this process involves setting up two clones, and not one.
To seize the domain roles (assume below the clone is named xyzzy), you must:
Note that if you have two domain controllers, you'll only need to seize onto one of them.
The filesystem cannot be cloned (despite what you would hope DFS does) and Windows does not let the backup program open a file that another program has open.
That means on a Windows server, any backup you take will not likely include a copy of the file you are most interested in.
On Windows Server 2003 and later, use the Volume Shadow Copy service. Almost any third-party backup utility you find will support this, including my winback utility.
Windows 2000 and earlier cannot take backups. My winback utility opens the hard disk in "raw mode", parses the NTFS filesystem, locates the files, and then streams whatever is on the disk to the backup target. This is not ideal, and is likely buggy. Do not rely on this kind of backup.
A backup can reliably be taken when the server is offline. Ghost, or other imaging software is great for this. Microsoft has a system called WDS that has an imaging software that can upload over the network, but it is difficult to use. If you have installed WDS for other reasons, you may want to use it simply to simplify your site.
A Linux-based LiveCD often includes ntfs-3g which can reliably copy files from a Windows server, but cannot be used as a backup tool, as there is no reliable way to restore it.
Windows 2003 has a tool for this called IISBack.vbs
It seems reliable. You run it like this:
CScript.exe IISBack.vbs /s xyzzy /u Administrator /p password /b BackupName
A restore can be done if you can open the IIS administrator. Right-click on the computer, and pick Backup/Restore Configuration. Select the backup in question on the Previous Backups, then click Restore.
Later versions of Windows have decided to switch to an XML-based format in %SystemRoot%\System32\Inetsrv\MetaBAse.xml and MSSchema.xml. On these systems, a filesystem backup is sufficient.
To back up the registry, use the System Restore tool by running: %SystemRoot%\System32\restore\rstrui.exe.
Microsoft offers a tool called ERD Commander which can restore checkpoints made. Make a bootable CD-ROM with it and make sure it works before relying on the System Restore tool.
There is also a tool to back up (export) registry keys. Running REG EXPORT HKCU C:\HKCU.REG will save a copy of the current user's registry hive. This form of backup cannot reliably be restored. Fortunately, portions of the registry backup can be edited with notepad.exe. To determine which parts are interesting, enable auditing of the registry before making changes:
NTBackup (A Microsoft backup tool) can also be used to back up "The System State" which includes boot files and other things. It cannot restore the registry reliably.
Exchange 2007 does not support filesystem backups until SP2 (see Backing up the Filesystem). Using local-continuous-replication copies of the database can be copied to another database at the expense of some performance. The replicated store can be dismounted and backed-up. Recovery appears reliable (using Setup /m:RecoverServer).
Post-office boxes can be downloaded reliably (and tested easily) into .pst files on Exchange 2007 on 32-bit systems only. This method is highly recommended because it is so easy to test, which means the backups tend to be very reliable.
get-mailbox | export-mailbox -PSTFolderPath:"y:\psts" -Confirm:$false
This saves each user's mailbox in a separate .pst file that can be mounted by Microsoft Outlook. After doing this, I recommend moving the pst files into another directory.
For versions prior to Exchange 2007, ExMerge.exe can also be used to copy Exchange mailboxes into .pst files.
There are a number of ways to back up an SQL database, but depending on how it is done it may be difficult to restore.
Replication is the easiest to test (simply point the application at the other server). Always use Snapshot publication when using replication as a backup strategy so that your testing doesn't accidentally affect your original database.
In SQL server 2005, you can use the T-SQL BACKUP DATABASE wat TO DISK='Y:\sql\d.bak' COPY_ONLY online, but you will want to RESTORE it to another server for testing. It seems highly reliable though.
The osql.exe can be used to issue SQL instructions from a command prompt.