# Commvault backup and recovery > Commvault associates virtual machines with a backup plan through VM groups --- Site [llms.txt](/llms.txt) --- Cloud Management Platform (CMP) imports those groups, so the choice on an order form is which VM group the new server should join. How Commvault identifies a machine determines what a restore produces. ## Prerequisites - A resource handler in CMP for a platform Commvault supports. - In Commvault: storage, a hypervisor, a server backup plan, and at least one VM group with that plan assigned to it. See [Commvault's documentation](https://documentation.commvault.com/) for how to set these up. ## Connect CMP to Commvault Follow [Add a data protection plan](/docs/cmp/configure/integrations/data-backup-and-recovery/add-protection-plan/) and choose the Commvault tile. Two points are specific to Commvault: - **IP address** takes the IP address or FQDN of your Commvault instance. Do not include a protocol prefix such as `https://`. - On the connection's **Protection Plans** tab, **Import Protection Plans** imports Commvault **VM groups**. Wherever CMP says protection plan, read VM group. ## Provision a server into a VM group Add the Data Protection Plan parameter where your servers are ordered, as described in [Data protection plan parameters](/docs/cmp/configure/integrations/data-backup-and-recovery/protection-plan-parameters/). A blueprint can pin the plan to a value or leave it to be chosen at order time. When the order runs, CMP adds the new server's hostname to the chosen VM group's contents. One Commvault step remains: run a backup job on that VM group. Until that job runs, the server does not exist in Commvault as a client. Afterward, backups follow the schedule in the VM group's server backup plan. ## How Commvault identifies a machine Commvault keys a machine on its hostname. When the machine is first discovered during a backup, it receives two identifiers, and from that point on, it can be managed individually in Commvault. - **Client ID**: an integer assigned to that hostname and kept across restores. - **GUID**: changes with every instance of the machine. Because the key is the hostname rather than the machine, deleting a server in CMP and provisioning a new one under the same name gives you the same client ID, and with it access to all the earlier backups taken under that name. ## What a Commvault restore produces Commvault offers several types of restores, most of which are aimed at individual files. CMP uses an in-place VM restore with unconditional overwrite. The virtual machine is replaced by a new machine of the same configuration, built from your chosen snapshot. So if you restore `dns1.mydomain.org`: - For inventory purposes, it is now a new machine carrying the old name. After the next Commvault backup, it has the same client ID and a new GUID. - At CMP's next VM sync, CMP finds the new machine and retires the old record. - The re-imported server has no Data Protection Plan value because a VM sync does not set one. It therefore has no **Data Protection** tab, and its backups are not reachable from CMP even though Commvault still holds them. Add the Data Protection Plan parameter to the server again to bring the tab back. For the restore procedure and how other technologies differ, see [Restore from snapshots](/docs/cmp/configure/integrations/data-backup-and-recovery/restore-from-snapshots/). ## Related - [Add a data protection plan](/docs/cmp/configure/integrations/data-backup-and-recovery/add-protection-plan/): The full connection and import procedure. - [Data protection plan parameters](/docs/cmp/configure/integrations/data-backup-and-recovery/protection-plan-parameters/): Making VM groups selectable on an order form. - [Restore from snapshots](/docs/cmp/configure/integrations/data-backup-and-recovery/restore-from-snapshots/): Restoring a server and what to expect per technology.