Data Protection Manager – how it works
Started off with the pain points (Recovery is unreliable & painful. Backup is too complex & slow. Costs are too high). Then to the ideal customer (medium sized data centers with 5-99 servers or large enterprises with remote offices) – but DPM is very good for customers of all sizes.
So the DPM agent (that gets installed onto the servers you want to manage) is going to capture byte-level changes to the disk. It can be installed on Windows 2000 SP4 or above (no support for 64-bit machines of clusters – yet). We recon there is a 3-5% overhead to the systems and you’ll need around 500Mb of free disk space (for the sync log) – but this is really dependant on how many changes are made between your snapshots. The agent installs a file system filter driver (FSRecord.sys) that copies the byte-level changes to the sync log – in a copy-on-write manner. The DMP File Agent service will copy the contents of the sync log to the DPM server (where it creates the replica of the data).
We currently only work with file data, although there is documentation on how to get it to look after SQL (KB 910401) and Exchange (KB 909644) – basically I stop writes to the databases and take a snapshot.
SP1 will introduce support for 64-bit machines and clusters. The next version (V2 – probably a year away) will work natively with SQL & Exchange.
We have two technologies that seem to do similar things: DPM and Windows 2003 R2’s File Replication Service with DFS (the branch office solution). To clarify the two, DPM is a Backup & Restore solution, while R2’s solution is for high availability of file data (local server dies, your files are still online on the replica).