The protecting procedure requires the following tasks be completed before you begin:
Use this procedure to manually specify details for multiple machines that you want to protect simultaneously using the Agent software. The details identify each machine on the network uniquely, and include connection information and credentials. This approach is often used when protecting Linux machines. However, using this process, you can protect only Windows machines, only Linux machines, or a combination of both.
The Protect Multiple Machines Wizard opens.
Optionally, if you do not wish to see the Welcome page for the Protect Machine Wizard in the future, select the option Skip this Welcome page the next time the wizard opens.
hostname::username::password::port
. The port setting is optional. The default port for installing Agent on Windows machines is 8006. For Linux machines, the default port is number 22 (SSH port). Examples include:
10.255.255.255::administrator::&11@yYz90z
Linux-host-00-2::administrator::p@$$w0rD::22
If the Protection page appears next in the Protect Multiple Machines Wizard, skip to step 11.
If the Agent software is not yet deployed to the machines you want to protect, or if any of the machines you specified cannot be protected for another reason, then the selected machines appear on the Warnings page.
|
Caution: Quest recommends this option. You must restart agent machines before they can be protected. Restarting ensures that the Agent service is running, and that proper kernel module is used to protect the machine, if relevant. |
The Protection page appears.
You can enter up to 64 characters. Do not use the special characters described in the topic prohibited characters. Additionally, do not begin the display name with any of the character combinations described in the topic prohibited phrases.
With a default protection schedule, the Core will take snapshots of all volumes on the protected machine once every hour. To change the protection settings at any time after you close the wizard, including choosing which volumes to protect, go to the Summary page for the specific protected machine.
Schedule options are added to the wizard workflow.
|
NOTE: Typically, it is good practice to protect, at minimum, the System Reserved volume and the volume with the operating system (typically the C drive). |
Text Box | Description |
---|---|
Name | Enter a name for the encryption key.
Encryption key names must contain between 1 and 64 alphanumeric characters. Do not use prohibited characters or prohibited phrases. |
Description | Enter a descriptive comment for the encryption key. This information appears in the Description field when viewing a list of encryption keys in the Rapid Recovery. Descriptions may contain up to 254 characters.
Best practice is to avoid using prohibited characters and prohibited phrases. |
Passphrase | Enter a passphrase used to control access.
Best practice is to avoid using prohibited characters. Record the passphrase in a secure location. Quest Data Protection Support cannot recover a passphrase. Once you create an encryption key and apply it to one or more protected machines, you cannot recover data if you lose the passphrase. |
Confirm passphrase | Re-enter the passphrase. It is used to confirm the passphrase entry. |
NOTE: This option is enabled by default, so if you do not want to encrypt data in this fashion, clear this option. |
|
NOTE: The first time protection is added for a machine, a base image (that is, a snapshot of all the data in the protected volumes) transfers to the repository indicated in your Rapid Recovery Core following the schedule you defined, unless you specified that the Core should initially pause protection. For information on pausing and resuming protection, see Pausing and resuming protection. |
You can monitor the progress as Rapid Recovery applies the protection polices and schedules to the machines.
The Events page displays, broken down by Tasks, Alerts, and Events. As volumes are transferred, the status, start times, and end times display in the Tasks pane.
You can also filter tasks by status (active, waiting, completed, queued, and failed). For more information, see Viewing tasks.
|
NOTE: To only see tasks that are waiting to be performed, make sure that you select the (Waiting Tasks) icon. |
As each protected machine is added, an alert is logged, which lists whether the operation was successful or if errors were logged. For more information, see Viewing alerts.
For information on viewing all events, see Viewing a journal of all logged events.
After a VM has been placed under agentless protection, you can support the Exchange or SQL application installed on that machine.
Before you begin, the following prerequisites must be in place.
winrm quickconfig
Complete the following steps to enable application support for agentlessly protected VMs.
If you want to add application credentials, you can do so by clicking SQL or Exchange at the top of the Summary page for the specific machine.
If you are protecting a Microsoft Exchange Server in your Core, there are additional settings you can configure in the Rapid Recovery Core Console, and there are additional functions you can perform.
A single setting, Enable automatic mountability check, is available in the Core Console related to Exchange Server. If enabled, Exchange server mountability checks are conducted automatically. This setting is available when the status for the protected machine is green (active) or yellow (paused).
For more information, see About Exchange database mountability checks.
You can also perform a mountability check on demand, from the Recovery Points pane on a protected Exchange server machine. For more information, see Forcing a mountability check of an Exchange database.
Following are functions you can perform for an Exchange server protected by the Core.
For more information about setting credentials for Exchange servers, see Setting credentials for an Exchange server machine.
For more information about truncating Exchange server logs on demand, see Forcing log truncation for an Exchange machine. This process can also be performed as part of the nightly jobs.
For more information about forcing a mountability check on demand, see Forcing a mountability check of an Exchange database.
You can also force a mountability check to occur automatically after each snapshot. For more information about mountability checks, see About Exchange database mountability checks.
For more information about forcing a checksum check on demand, see Forcing a checksum check of Exchange database files.
You can truncate Exchange logs and force a checksum check as part of nightly jobs. For more information about the tasks you can schedule as nightly jobs, see Understanding nightly jobs. For information on configuring nightly jobs, see Configuring nightly jobs for the Core.
© ALL RIGHTS RESERVED. Nutzungsbedingungen Datenschutz Cookie Preference Center