| REPLICATION SERVER. The most important | | | | as this is ready, probably within an hour, the primary |
| characteristic of HAP is support for replication of the | | | | server is ready for backups and restores. While the |
| primary backup appliance. This lets the user copy all | | | | secondary partition is being checked, the incoming |
| incoming blocks and meta-information to the | | | | blocks for backups are stored on the first partition |
| replication server. Of course this happens without | | | | until it is 95% full. This functionality is available on |
| interrupting the backup process. The replication | | | | single and replicated setups. |
| server is a Backup Appliance. Just like with every | | | | If the primary partition is available, but the secondary |
| other our Backup Appliance, all HAP settings are | | | | is not available yet, restores can be performed by |
| placed on the primary server. The number of | | | | approaching the binary blocks on the replica server. |
| replicated appliances is unlimited It is possible to | | | | This is done automatically when the storage on the |
| connect three, four or even more to each other as a | | | | primary appliance is not available. |
| backup for the backups of the backups. Each | | | | ADDING STORAGE. HAP also lets the user add |
| incoming block is sent to the replica server as soon | | | | storage to a backup appliance. This can be direct |
| as it is available. If the replica server is not available | | | | attached storage, UNC storage. Fiber attached SANs |
| temporarily, the primary server keeps track of which | | | | or NASs and even USB disks (not recommended). |
| blocks have not been replicated yet. The meta | | | | Adding storage demands special expertise and is |
| information is still replicated by the database engine | | | | therefore implemented from your sales contact |
| that is in use and can also pick up everything after | | | | person. |
| temporary non-availability of the replica server. The | | | | NO AUTOMATIC FALLBACK. The HAP is not an |
| status of the replication can be seen in the console. | | | | automatic fallback system. If the primary appliance is |
| POWER LOSS. One of the most critical events for a | | | | no longer available for reasons such as theft or fire, |
| backup server is power loss. 95% of all appliances | | | | the replica appliance must be upgraded to a primary |
| are in a data centre. Although it should not happen, | | | | appliance. This can be done by the technicians by |
| reality has taught: us that power loss in a data centre | | | | changing the BSP code. Although this is only a small |
| does actually occur. The problem here is that the OS | | | | chore, it has major consequences. It is not possible |
| for the appliance will check all storage before it is | | | | to reverse this process without copying the |
| available for the new backup. This can last 12 hours | | | | metadatabase. This not only takes a lot of time, but |
| on a 10TB system with a lot of information. To | | | | moreover both servers are unavailable during this |
| prevent this the 7D appliance and 14D appliance have | | | | copying process. Depending on the available binary |
| two partitions This first partition contains 5% of the | | | | blocks on the new replica server, it can also take up |
| available storage and the second partition 95% of | | | | a lot of time to replicate the binary blocks again. This |
| the storage. In the case of a power loss or other | | | | depends on the volume, the delays in the network |
| cause that forces the OS to check all of the available | | | | and the available bandwidth. |
| storage, the first partition is checked first. As soon | | | | |