How to Create and Manage a Federated Repository with NAKIVO

Over time, backups consume more storage space and hence disk space as the amount of backed-up data continues to grow. You may be using incremental technologies to skip duplicate data blocks. You may also be implementing a sound retention policy where unneeded recovery points are deleted. However, at some point, you may need to add more disks and expand a backup repository to accommodate more backup data to avoid interrupting your data protection workflows.

With regular backup repositories, you can create a new repository to add storage space for backups, but you might need to reconfigure your backup jobs or create new ones. This may lead to disruptions and retention gaps. To simplify expanding repositories and avoid failed backup jobs due to insufficient storage space, NAKIVO Backup & Replication offers the Federated Repository feature, allowing administrators to flexibly add storage space while using existing backup configurations. Let’s look at what Federated Repository is and how it works.

Ensure Availability with NAKIVO

Meet strict requirements for service availability in virtual infrastructures. Achieve uptime objectives with robust DR orchestration and automation features.

DISCOVER SOLUTION

What Is a Backup Repository?

A backup repository in NAKIVO Backup & Replication is a storage location with a specific format for storing backup data (recovery points) and any necessary metadata. Along with the Director and Transporter, the backup repository constitutes one of the three core components of the NAKIVO solution. Backup repositories can have two data storage types: incremental with full or forever incremental.

A backup repository includes the following elements:

• A backup object is a copy of the source object. The backup object is created by NAKIVO Backup & Replication and stored in a proprietary form within a backup repository.

  A backup object can consist of one or more recovery points.

• A recovery point is a specific instance of the backup object representing the state of the source object at a particular point in time. In NAKIVO Backup & Replication, a recovery point can be full or incremental.
• A recovery point chain (specific to incremental with full repositories) is a series of related incremental recovery points with dependencies between them. A chain begins with a full backup and includes all associated incremental recovery points.

  A backup object can contain multiple chains, where each chain starts with a full recovery point and ends with an incremental recovery point. Multiple chains form a backup set.

• Metadata is the auxiliary information associated with a repository, backup object or recovery point. This metadata is critical for managing backups and restoring data from backups.

Each backup object contains recovery points that represent the state of the source object at a particular moment. Each backup object has one or multiple recovery points.

What Is a Federated Repository?

A Federate Repository in NAKIVO Backup & Replication is a backup repository that consists of one or more backup repositories, called members, and can be scaled horizontally with the addition of more backup repositories. A federated repository can be represented as a logical pool containing existing backup repositories. A federated repository can also be referred to as a scale-out repository due to its flexible capabilities providing horizontal scaling.

A federated repository member is a backup repository used as part of a federated backup repository. A federated or scale-out repository can consist of one or more repository members.

How the Federated Repository Works in NAKIVO Backup & Replication

On the left side of the diagram below, you can see an incremental with periodic full type of backup repository used in NAKIVO Backup & Replication. On the right hand, you can see a federated backup repository.

First, let’s see how backup jobs work in an incremental with periodic full repository (Repo A). There are two backup jobs – Job A and Job B. These jobs create backup object A (BO A) and backup object B (BO B) respectively. Each backup object consists of a number of recovery points. RP-F is the full recovery point and RP-I is an incremental recovery point. A backup can consist of multiple recovery points, which can form a chain of recovery points. A chain starts with a full recovery point followed by a number of incremental recovery points. When another full recovery point is created, a new chain of recovery points is started.

A federated backup repository is basically a logical pool of backup repositories (of the type incremental with periodic full backups). We also have two backup jobs in the federated repository – Job A and Job B. One backup object can be spread across several member repositories (Repo A and Repo B) that are members of the same federated repository.

There is one chain starting with a full recovery point and a couple of incremental recovery points for Job A. We can continue writing data to the next repository (Repo B) in the pool starting with the full recovery point. This process can be scaled out further if needed with Repo C, Repo D, etc.

Note that you cannot break one single chain of recovery points across several member repositories. If backup data is written to another member in a federated repository, then the NAKIVO solution creates a full recovery point first regardless of the backup job settings for the full backup schedule.

This means that one backup object can be stored across multiple federated repository members. However, one recovery point chain within a backup object should be self-contained within one federated repository member, that is, all dependent recovery points are stored in the same federated repository member.

In case a job has to select the next member as the destination, the next backup run will create a full recovery point. This allows data to be restored from a recovery point even if another member of the federated repository is inaccessible.

Only repositories configured for incremental with full backups can be used as members of a federated repository. Forever-incremental backup repositories are not supported for this feature.

The following storage types can be used to create member backup repositories:

• Local folder on a machine with the assigned Transporter component of the NAKIVO solution
• NFS share
• SMB share

The maximum number of federated repository members is 128.

The Federated Repository feature is available for the Enterprise Plus and MSP Enterprise Plus editions of NAKIVO Backup & Replication. The feature does not consume any licensed units in addition to those consumed by data protection activities.

You can learn more about Federated Repositories in NAKIVO Backup & Replication and how it works in this video:

Benefits of a Federated Repository: Uninterrupted Data Protection

The demand for scalable and flexible backup storage is always growing. Traditional backup repositories often face scalability limitations, performance bottlenecks and complexity with large data volumes.

A conventional backup repository can be viewed as a folder that can have as much free space available for backups as the underlying system allows. Extending a conventional repository when one needs more storage for specific jobs can be a challenging task. This process requires more time and effort to configure while backup jobs are suspended.

Configuring a federated repository addresses these challenges by enabling seamless expansion of storage capacity, enhanced fault tolerance, and better resource utilization across distributed environments.

Federated repositories are especially useful for large organizations with complex infrastructures and tight backup schedules. Storage consumption in backup repositories usually increases gradually and can be uneven. In this case, an organization can end up with a large number of backup repositories with only limited free space remaining on each backup repository. As a result, it can’t ensure that there is enough free space for future backup jobs to complete. An example of this situation is illustrated in the table below.

In this example, if there is not enough space in one of the repositories for a configured backup job, the system administrator should create another backup job to a different repository with enough free space. This approach to managing tens of “small” repositories is not convenient in a large infrastructure. At the same time, the free space on each individual repository is wasted because it cannot be used to continue writing backup data by using an existing backup job.

If we sum up the total number of free spaces in all backup repositories, the amount is not as low as it is for each repository individually. Aggregating the amount of free space allows you to use disk space more rationally without the need to redistribute existing backups among the repositories. You can combine multiple existing backup repositories into a federated repository to aggregate free space from multiple repositories and continue running jobs.

If the initial member of a federated repository does not have enough space, the NAKIVO solution uses its algorithm to select the next available member in the federated repository, that is the best candidate to continue writing the data for a backup object.

The advantages of using a federated repository are:

• Backup jobs continue running even if the target repository is inaccessible or out of space.
• Users save time and effort by allowing simplified scaling of backup storage to meet evolving backup and recovery requirements without disruption.
• Improves reliability and enhanced data protection. Reduces the risk of data loss and downtime for an organization by implementing robust backup and recovery capabilities supported by a scalable and resilient storage infrastructure.
• Allows for simpler backup data migration between repositories.

Setting Up a Federated Repository in NAKIVO Backup & Replication

Let’s look at how to configure a federated repository in NAKIVO Backup & Replication. Suppose we added two hard disk drives to our backup server and want to use the disk space on these drives to store backups using a federated repository. For starters, we have one backup repository called Main repo. There is a backup job that uses the Main repo as a destination.

First, we need to create a backup repository on a new hard disk drive that we recently installed. Then, we will use this repository as a member in the federated repository configuration.

Creating a federated repository member

1. In the web interface of the NAKIVO solution, go to Settings > Repositories, click + and hit Create a new backup repository.

   

2. Select Local Folder in the repository type if you are using a locally installed hard disk drive. You can also use a file share. Click Next to continue.

   

3. Specify the name and location of the new backup repository. Note that you must create a directory with the correct permissions before you complete this step. In our case, the parameters are:
   • Name: repo1
   • Assigned transporter: Onboard transporter
   • Path to the local folder: /opt/nakivo/repo1

   NOTE: This directory was created on our backup server running on Linux and /etc/fstab was adjusted for auto-mounting. You must create a directory and set permissions before configuring a backup repository in the NAKIVO web interface.

   

4. Select new backup repository options. You can use the default values to use this repository as a member of a federated repository. Hit Finish.

   

Similarly, you can create more backup repositories and add them as members in your federated repository. In this example, we have created two new repositories called repo1 and repo2, which you can see in the screenshot below.

Configuring a federated repository

1. Go to Settings > Repositories, hit + and click Create federated backup repository.

   

2. If an existing backup repository contains recovery points of a backup job, a notification message about affected jobs is displayed. As our Main repo contains recovery points, we can see the following message:

   Selected repository is used by the following jobs. The Jobs will be automatically updated to use federated repository.

   Click Proceed.

   

3. Select the members of a federated repository. We select Main repo, repo1 and repo2 as members of the federated backup repository. Hit Next.

   NOTE: If a backup repository is used to store NAKIVO Backup & Replication self-backups, it cannot be added to a federated repository. If the selected members support immutability and contain at least one immutable object (or are associated with a job configured to create an immutable recovery point), the members that do not support immutability are disabled.

   

4. Specify the federated repository options, including the name and description.
   • Name: Scale out repository
   • Description: Main repository + repo1 + repo2

   Click Finish.

   

Managing Federated Repositories in NAKIVO Backup & Replication

Now, you can see the scale-out repository in the list of backup repositories. The repository size is the sum of the three-member repositories. You can click the federated repository to see the details.

The repository information includes members and backup jobs using this repository. Click any of the federated repository members to see the details about that repository and the associated backup jobs.

In the screenshot below, we can see the information about Main repo. One backup job is using this repository.

The backup job destination location is automatically adjusted to use the federated repository. You can click the job name and check these settings if needed.

Migrating backup data to another member

You can migrate backups from one federated repository member to another. This option can be useful if you are reorganizing the configuration of the scale-out repository to remove one of the members for example.

To migrate backup data:

1. Go to Settings > Repositories and click the federated repository (scale out repository in this case).
2. Click the federated repository member, which is the backup storage from which you want to migrate. We select Main repo in this example.
3. On the repository information page, click the … (three dots) icon and hit Lock in the menu that opens.

   

4. The confirmation message Lock the member? is displayed. Click Lock to confirm.

   

5. Once the federated repository member has been locked, select the backup(s) you want to migrate, click the … (three dots) button and hit Migrate backup.

   

6. A notification message warns you about the backup migration to other repository members. Read the message and click Proceed to continue.

   

Removing a repository member

1. To remove a federated repository member, go to Settings > Repositories and click the federated repository (scale-out repository in this case).
2. Hover over the repository member you want to remove, click the … (three dots) icon and hit Remove in the menu that opens.

   

Conclusion

A federated backup repository, also known as a scale-out backup repository, is a useful feature to configure scalable and reliable backup storage. The logical structure of this repository allows you to use storage space more rationally and improve the reliability of your backup system by avoiding situations when a backup job fails due to the lack of free space. Instead of spending time reconfiguring an existing backup job to use another repository, you can add a new federated repository member and continue running the existing backup job.

Try NAKIVO Backup & Replication

Get a free trial to explore all the solution’s data protection capabilities. 15 days for free. Zero feature or capacity limitations. No credit card required.

Try for Free