LucidLink Backup Repository for Veeam Backup and Replication

  • Updated

LucidLink supports being run as a back-end volume to backup products such as Veeam Backup and Replication. 

 

This allows you to offload data to cloud object storage without licensing implications or needing to purchase additional disk for backup staging. Allowing you to leverage normal Veeam Backup and or Backup Copy Jobs without complex repository configuration to send data directly to the cloud. With snapshot support LucidLink offers the ability to protect against ransomware attacks, by providing an additional line of defense from malicious data access or deletion.

 

In order to use LucidLink with Veeam, first you need to create a LucidLink Filespace: 

  1. If you do not have a user account, create one and then set up a filespace to use the object storage of your choice. Note that for on-premises object storage region information may be custom specific to your deployment. Be sure to review LucidLink setup information relating to your object storage vendor.

  2. Download and install the LucidLink Client for Windows or Linux on your Veeam Backup Repository server.

  3. Initialize your filespace with a specific block size. Choose a block size that matches your Veeam backup block size. A 1MB block size is recommended for Veeam Backup and Replication. This is can be done either via the advanced options in the web portal, or via the command line and cannot be changed after initialization.

    lucid init-s3 --fs <filespace.domain> --password <rootpassword> --endpoint <ipaddress/url:port> --access-key <accesskey> --secret-key <secretkey> --https --region <region> --block-size <KiB> --provider <vendor>

  4.  By default LucidLink configuration is stored in the active user profile. However to ensure that LucidLink runs even if no users are logged on, you need to configure this to run as a service. You can run LucidLink as a service on Windows and for a service on Linux you can use systemd. Ensure that the service is configured to start before Veeam requires the LucidLink mount point.

  5. Configure a cache size to meet your requirements. You can choose a different cache size or different cache location to allow more data to be stored locally. The default cache is 25GB. LucidLink reserves 10% of its overall cache for reads. This allows frequently read data from the cloud to be stored locally, even if the write portion of the cache is full. It may make sense to make the overall cache larger depending on your design goals, and the speed of your network or internet connection. A cache of 10-100GB may make sense.

  6. Configure a retention style to meet LucidLink requirements. You can use different retention models based on how you are charged for object storage. LucidLink will work best with Backup Jobs with Forward Incrementals and Active Fulls, Backup Jobs with Forever Forward Incremental or Backup Copy Jobs with Active Fulls. Due to the nature of object storage, synthetic fulls would result in significant object storage egress charges. We also recommend that you use per-VM backup chains for backup storage. It may help to schedule full backup operations over the course of the week, to reduce overall bandwidth requirements.

    Note that Veeam Backup and Replication 12 with default settings sets Backup Jobs to use Forward Incremental and Synthetic Full and Backup Copy Jobs set without Active Fulls. If you are being charged for data egress you can change to Forward Incremental with Active Full or Backup Copy with Active Full before sending data to LucidLink.

    Some object storage providers charge for early data deletion. As your file blocks change you may have to account for object storage early deletion charges, this is usually equivalent to the change rate in your backup set.

 

LucidLink supports all restore features you would expect from Veeam Backup and Replication. This includes instant recovery, application-item restore and search inside a backup file. Should restores be from public cloud object storage, there may be egress charges relating to these operations. Search operations across large application data sets may take longer than if these were stored on local disk. However a standard instant recovery should fetch only the data as needed from a backup set, and stream this from object storage on-demand. 

 

Was this article helpful?

0 out of 0 found this helpful