Define in detail the best practices for deploying a UEB system.
Unitrends Enterprise Backup (UEB) is distributed initially as a pre-packaged ready to boot VM for either VMWare or Hyper-V. Though ready to boot, it is packaged by default in a strictly minimal configuration that is intended only for limited testing or use, and after initial deployment, several configuration processes are required before the virtual backup appliance can function properly and reliably in a production environment.
The default UEB is a 138GB machine using 2 CPU cores and 4GB of RAM. Though sufficient for initial deployment and testing, additional storage is required not only for backups, but for internal long-term storage of logs, database information, and necessary temp space for many operations. Additionally, only the smallest deployments can support reliable performance on only 2 CPU cores and 4GB of RAM.
Memory and CPU
For most deployments, a minimum of 4 CPU cores and 8GB of RAM should always be assigned to a UEB. Over time, the System Load should be monitored and additional cores and memory is required for medium and large deployments. When system load is commonly averaging in the yellow or when utilized system RAM is commonly in heavy use, additional resources may be required. As with Unitrends hardware appliances, configurations of as many as 12 modern Xeon cores and 64+GB of RAM may be required for efficient operation in some very large environments, though at such large scale operating more than one UEB is typically preferable to a single large system.
Internal Storage Size
The UEB requires a minimum of 128GB for the /Backups partition. It is not uncommon for the databases and other normal files occupying space in the UEB default image to use significantly more. It is best practice to add not less than 120 additional GB of storage to the default UEB’s internal disk making the default storage at least 256GB total, but larger disk sizes may be necessary. If space in /backups becomes low, adding additional VM disks and expanding the /backups partition may be necessary. Be sure to deploy the UEB to a system that can accommodate increasing this size in the future as necessary. Because the databases for the UEB exist in this default storage, it is critical that this storage not be allowed to become completely full unexpectedly as this may cause database corruption or other undesirable operation.
Additional Internal storage for Temp space for Vaulting or Replication
Vaulting and Replication both require temporary space for processing data to be sent to the Target. The size of this space is generally not recommended to be less than the size of the largest backup to be replicated. A minimum of 128GB additional storage beyond the UEB’s default is required for replication to function, but more may be necessary. Vaulting temp space is configured in vault configuration and not less than that amount of space should also be configured for the UEB’s internal disks.
Additional Backup Storage
The best practice is for all backup storage on UEBs to be accommodated in VMDK or VMHD files as expanded internal storage. This provides the best long term flexibility of the unit as internal storage is readily expanded without creating new additional disk to disk devices. By using only the single D2Dbackups default container, scheduling is simplified, the SIS (Single Instance Storage) and deduplication work globally for all backups, and adding additional storage later requires only a simple action that does not require modifying backup schedules to accommodate using.
If local VM or a single SAN infrastructure is insufficient to contain a sufficient number of 2TB VM disks for internal UEB disk use then it is recommended external-only storage be used for backups. It is still a requirement to grow the internal storage to at least 128GB or more, however, an additional disk device for backups should be added externally and used for all backups, being made the default and ensuring backups are not directed to internal storage at all. If SAN is used, it is the best practice to connect the SAN to the VM host and not the UEB itself and place VMs and the UEB disk itself in that storage allowing them to be aggregated into a single /backups partition, but if that is not possible, please contact your Unitrends Sales Engineer or consult the Unitrends Professional Installation Services Team for advice in storage configuration. Storage added to a UEB CANNOT be removed once added for backups use. Be sure you understand the limitations and benefits of each storage type before you make a decision on a deployment plan.
The UEB initial VM disk and this additional backup storage should be in the same storage pool if possible, and if not on disk in the same topology and of the same performance when expanded.
Thick provisioned media is strongly recommended. The UEB design intent is to keep storage as full as possible at all times to maximize retention of backups, therefore, the common benefits of dynamic or thin provisioned storage are not applicable to the UEB, and the performance disadvantages inherent to thin provisioned storage may be a concern.
Use of different performance tiers of disk for multiple VMDKs or VHDs added to a UEB’s internal storage can produce undesirable results up to and including complete LVM corruption and loss of all backed up data and UEB configuration!
Storage used for the UEB’s internal storage, most especially for large UEB deployments or when replication is utilized should be of adequate performance as would normally be intended for database servers or other high performance applications. RAID 5 or 6 disks are preferred running at 7200RPM or faster on business or enterprise class drives. For extremely large deployments, higher performance disks may yield better results.
NAS Device Considerations
NAS devices used as backups storage are a fully supported aspect of UEB deployments, however, caution should be utilized when selecting CIFS or NFS mounts for backups storage vs SAN, iSCSI, or native VM Disks. Many NAS devices support a Max 2TB file size which can be an issue backing up some large clients. Additionally, some NAS units may have difficulty supporting the nature of the SIS deduplication repository used in the D2D device as this can contain millions of small blocks and this structure can be highly intense I/O process that may be limited in performance or reliability by the latency inherent to the NAS appliance or the network connection to the remote storage.
A NAS should be considered the slowest and least recommended topology when selecting between local datastores, SAN, iSCSI, and NAS options and is more suited to archival use than for backup storage except in small or low data-change environments. If a NAS is used for backup storage, disabling deduplication may be necessary to achieve sufficient system performance in some situations.
Storage Architecture Considerations
The UEB needs to be in constant communication with all of its backup storage. It is critical that all UEB storage be on the same power reliability or physical platform. Unitrends does not recommend spreading multiple D2D devices across disparate storage systems which might lose power independently of each other. Use of such architecture is certain to lead to data loss in the UEB. Disparate storage for internal /backups expansion IS NOT SUPPROTED. Internal UEB storage is an LVM, and even momentary disconnection from some VM disks and not others will cause data loss.
If you have questions about how to architect your UEB deployment, Unitrends strongly encourages you to speak with a Sales Engineer, or, seek professional deployment services prior to beginning your installation. If you are considdering purchasing additional hardware to support a UEB, please let the Unitrends Sales Team help guide you to equipment that compllies with our best practices. Deploy it right the first time!
14th of January, 2014