How to do it...

1. First things first, you want to decide how to deploy DPM server:
   • Virtual or physical deployment
   • Deduping DPM data
   • SQL Server consideration
   • DPM server requirement
   • Disks and storage consumption

A common question that we have heard a lot is, can we deploy DPM in a virtual or physical machine? The DPM server can be deployed either in a physical deployment or via a virtual machine. However, running DPM in a virtual machine has more benefits, such as the following:

• • It is easier to move the DPM server to new hardware if needed (portability).
  • Easier to recover (protected DPM virtual machine).
  • You can enable de-duplication on the VHDXs attached to the DPM server. The VHDXs files could reside on a Scale-Out File Server (SOFS), on a Storage Spaces Direct (S2D) cluster, or any other type of storage, such as NAS or SAN.

1. Backup storage is one of the top consumers of storage infrastructure, so storage optimization techniques such as compression and de-duplication have always been priorities for backup IT administrators.
2. De-duplication involves locating duplicate blocks of storage and replacing them with a reference and a single instance of the duplicate block. Depending on the workload that is being written to the storage and the block sizes used to perform the de-duplication, storage savings can range anywhere from 50 to 90 percent.
3. With the introduction of S2D in Windows Server 2016 and Storage Spaces with SOFS in Windows Server 2012 R2, customers can create commodity storage that is built natively on a Windows-based server with local attached storage in S2D as well as Windows-based servers with JBODs, which can be a viable alternative to traditional SANs.

1. For DPM deployments, you need to have the following:

   • An instance of SQL Server installed and running to host the DPM database. The instance can be collocated on the DPM server or remotely.
   • A disk to be used as a dedicated space for DPM backup storage.
   • A DPM protection agent installed on the computers and servers you want to protect.
2. DPM uses SQL Server as a database to store backup information for the workloads, servers, and computers it protects. At the time of writing this book, the following SQL Server versions are supported with DPM Long-Term Servicing Channel (LTSC) and Semi-Annual Channel (SAC):
   • SQL Server 2017: Standard or Enterprise 64-bit (starting with DPM 2019 and DPM 1901 onward)
   • SQL Server 2017: Standard or Enterprise 64-bit (starting with DPM 1801 and DPM 1807 as upgrade only); you can upgrade SQL Server 2016 and SQL Server 2016 SP1/SP2, to SQL Server 2017
   • SQL Server 2016: Standard or Enterprise 64-bit (starting with DPM 2016 with Update Rollup 2 onward)
   • SQL Server 2014: Standard or Enterprise 64-bit with all service packs and updates
   • SQL Server 2012 SP2 onward: Standard or Enterprise 64-bit

1. DPM server is designed to run on a dedicated, single-purpose server. The following applications and roles are not supported to run side-by-side with DPM:
   • Application server role
   • Operations Manager Management server
   • Exchange server
   • A server running on a cluster node

1. The following Windows Server operating systems are supported with DPM 2016 or later:
   • Windows Server 2019, Datacenter and Standard editions
   • Windows Server 2016, Datacenter and Standard editions
   • Windows Server 2012 R2, Datacenter and Standard editions

1. System Center Data Protection Manager (SC DPM) can use any type of disk that is presented as local attached storage. DPM can use any of the following:

   • Direct Attached Storage (DAS)
   • Fiber Channel Storage Area Network (FC SAN)
   • iSCSI Network Attached Storage (NAS)
   • Hyper-V Virtual Hard Disks (VHDX)

As discussed earlier, DPM 2016 or later on Windows Server 2016 and Windows Server 2019 comes with MBS, which uses ReFS Block-Cloning technology for storing backup files. This leads to immense storage and performance savings. Furthermore, DPM uses incremental backups to store data. This means that it will transfer the complete data to be backed up initially. After that, it will transfer only the changed bits. Hence, the size of the data is determined by the initial size, the size of the changed bits (which depends on the churn percentage and the total size), the number of recovery points per day, and the retention period of the copies. Hence, small data, with a small churn, may take up more space if there are a large number of copies stored per day, and if they are retained for a long time.