In this text, we seek to list good configuration practices so that the Fenix DFA functions can be better utilized. These are the main functionalities of the tool:
- Record the history of backup executions in an extended and reliable manner – regardless of the tools used;
- Consolidate and monitor backup executions;
- Facilitate the visualization of backup versions with valid retention;
- Relate backup incidents to executions, generating traceability of failures;
- Identify risks regarding certain practical behaviors of backup executions;
- Assist in the collection of reports for audits;
- Organize restoration evidence;
- Segmented view between Manager, Client and operator;
Below we will demonstrate some configurations and best implementation practices.
- Organizational structure;
When creating the company and branches, we must pay attention to the structure and nomenclature of the companies created, since the permission to view data imported from the connections is inherited from the branches;
When creating the company and branches, we must pay attention to the structure and nomenclature of the companies created, since the permission to view data imported from the connections is inherited from the branches;
When creating the connection, we must select which branch will belong to this connection.
Still in the context of users, it is worth remembering that users with a “client” profile are those with a restricted view of the tool, without access to technical activities, such as incidents, and may have even more limited access with the addition of the “Virtual Location”, thus, specific business areas may have limited view of the policies and assets that are relevant to them.
Ideally, a company organizational chart can be created so that the configured structure is adherent.
- Connections
Any failure in the connection between Fenix DFA and the backup software will cause synchronization failure in the system, so we must prevent possible errors in this import.
For large environments (over 1000 daily executions), it is recommended that the Fenix agent be installed on a server separate from the backup server, and that it respects the resource consumption requirements described in the system manual.
It is worth remembering that the agent must always be run with administrator permission.
We must also be careful with data duplication.
If two or more connections are created for the same environment and the same backup tool, the data in Fenix DFA will be duplicated, because the system understands that the connection is unique, they are different data, regardless of whether they have the same name. Therefore, if connection errors occur, the agent logs must be analyzed, check the connection with the Fenix DFA server and, if the connection is not resolved, open a case with Fenix DFA support.
- Incident Handling
Incident management by Fenix DFA is one of the main modules of the system and offers several benefits. However, care must be taken when using it, since incorrectly documenting incidents can lead to problems with the integrity and traceability of backup failures.
Incident merging: This function was developed so that multiple failures, whether they belong to the same policy, are handled in the same flow, and therefore must have the same cause and solution. The merging cannot be undone, so we must pay attention to the selection of policies at the time of the operation.
There is the option to merge incidents individually or all of them; in this process, the page filter can be used to facilitate mass operations.
Closing Status: The closing status of an incident cannot be changed and may cause inaccurate information in the tracking. If it is closed as “successful”, Fenix DFA will understand that that session is valid as a backup/restore position, and its identification will turn green on the execution panel. This status should only be used when you are sure that the data was saved successfully. When the backup is marked as “lost”, the system uses this information to calculate the SLA and marks the session as unavailable for restoration.
Reprocessing: There is an option during incident management that allows the analyst to specify which sessions, within those merged incidents, were unsuccessful attempts to reprocess the backup. This option will cause these errors to be purged from the SLA. On the other hand, if the error was successfully reprocessed, the analyst must indicate the session (or sessions) related to this failure. This relationship will be visible on the execution panel.
- Risk Management
The proper use of this module of the tool can identify “gaps”, locate failures in the executions and in the configurations of the backup policies. Risk management analyzes important metrics for managing backups:
These analysis options are available individually for each backup policy in the “Audit Policies” section.
Disable Analysis: It is essential that policies that do not adhere to the above metrics have their analyses disabled, otherwise “false” risks will be generated.
Examples:
Archivelogs: Database log copy routines typically run multiple times per day and copy logs that may or may not have been generated by the database, so “size”, “duration” and “empty job” analyses should not be analyzed.
Unmanaged Policies: Backup policies that are not directly controlled by the backup software, initiated by the client or by third-party software, may have parameters that make them ineligible for “policy disabled” or “server removed from policy” analysis.
Generic Policies: Policies that do not explicitly specify in their configuration which assets are copied will not be able to be analyzed due to “server removed from policy”. They will also be compromised in their analysis of “size” and “duration”, since, as they are generic, assets can be added or removed, modifying their parameters.
Backup Software: Still on the risk analysis aspect, there are some practices that can also be adopted by the backup software, which will facilitate the analysis by Fenix:
- Separate the routines into individual servers (or groups in the case of large environments), with the asset selection specified in the policy;
- Separate the policies according to their frequency, daily, weekly, monthly, etc.