NAKIVO Backup & Replication Component: Backup Repository
NAKIVO Backup & Replication has three core components: Director, Transporter, and Backup Repository. While the Director is used to manage everything, the Transporter is used for data transfers between nodes. In this guide, we explain how to create and configure a Backup Repository in the NAKIVO solution and cover the supported features and platforms.
What Is a Backup Repository?
A Backup Repository is a core component of NAKIVO Backup & Replication where backups (recovery points) are stored. It is a designated folder for housing backups and backup metadata generated by the solution. When you deploy the backup solution on a supported OS, you can automatically create a directory for the default onboard repository. In Windows, this directory is called “NakivoBackup” and in Linux it is called “repository“. This folder can then be used as a repository for backed-up data and Backup Repository metadata.
IMPORTANT: Under no circumstances should you manually alter or delete any files in the “NakivoBackup” folder. Doing this could lead to permanent damage to the entire Backup Repository, which is irreversible, and to backup data loss.
NOTE: To prevent any disruption to operations in the NAKIVO solution and potential data corruption, you should add the application to the whitelist or exclusions list of the antivirus software running on the machine where the NAKIVO Backup Repository is deployed.
Upon installing the full solution (Director and Transporter components), a Backup Repository is automatically created as the default setting. This default Backup Repository is given the name “Onboard repository” (this name is displayed in the web interface).
Supported Storage Media and Platforms
NAKIVO Backup & Replication supports different storage media and platforms for creating a Backup Repository:
- Local Folder, which is a directory on the file system of the machine where a Transporter is installed
- NFS and SMB shares
- Public clouds (Amazon S3, Microsoft Azure, Wasabi, Backblaze B2) and other S3-compatible storages (Cloudian, MinIO, Ceph, C2 Object Storage, Lyve Cloud, etc.)
- SaaS
The SaaS repository is a special repository type used to store Office 365 backups. This repository type is created in a local directory for the assigned Transporter. The Backup Repository can be created on ext3, ext4, NTFS, and FAT32 file systems.
- Deduplication appliances with support for native protocols
Types of Backup Repository
NAKIVO Backup & Replication provides two backup data storage types for incremental backup:
- Incremental with full backups. NAKIVO Backup & Replication creates a full backup on the first backup job run and subsequently allows you to create full and incremental recovery points depending on your needs. The solution allows you to periodically create synthetic full backups based on the backup job settings.
- Forever-incremental backups. The solution creates a full backup only on the first backup job run. All consequent job runs will send only changed data (increments) to the Backup Repository.
Starting from version 10.4, the incremental with full backup setting is applied by default when creating a new Backup Repository (instead of creating a forever-incremental Backup Repository as it was prior to v.10.4). The type of storage can be configured during repository creation.
Backup Repository size
It is recommended that each Backup Repository in NAKIVO Backup & Replication hold up to 128 TB of backup data after compression and deduplication. You can create up to 500 number of Backup Repositories per solution installation.
Each new Backup Repository requires at least 5 GB of free space in addition to the 5 GB of free space required for the successful operation of an existing Backup Repository. The solution automatically checks for free space every 1 minute if there is more than 10 GB of free space. If there is less than 10 GB of free space, the check process is done every 10 seconds to avoid errors caused by a lack of disk space.
Scalability
A specific Backup Repository is controlled by a single Transporter known as the Assigned Transporter. In simpler terms, only one Transporter is authorized to read and write data to a specific Backup Repository. The Assigned Transporter takes full responsibility for all interactions related to its respective Backup Repository. A single Transporter can be assigned to and effectively manage multiple Backup Repositories simultaneously.
A single Backup Repository cannot be used by more than one Director/Tenant at a time.
Backup Repository Features
A Backup Repository supports many useful features, including:
- Deduplication. Backup Repositories can be configured to use the Global Deduplication feature to deduplicate backup data at the block level. Duplicate data blocks are excluded from a backup regardless of the source of data, which effectively saves storage space. Note that feature can only be used with the forever-incremental Backup Repository.
- Compression. Data in a Backup Repository can be compressed using three compression levels from low to high. Thus you can balance between saving storage space and loading the CPU to compress data. Compression can be configured when creating a new Backup Repository.
- Encryption. A Backup Repository (when installed on Linux) can be encrypted to protect all backup data stored in the repository using an encryption password. Encryption has an impact on the backup speed.
- Space reclamation. Unused space reclamation allows you to compact a Backup Repository size and reclaim unused space when using a forever incremental backup storage type.
- Backup Repository self-healing. This feature verifies issues caused by data inconsistency (including metadata), checks data integrity, and repairs errors when it is possible. Backup Repository self-healing can run automatically, on schedule, and manually. You can perform full data verification as well. Full data verification in a Backup Repository is supported. This feature can protect a repository against corruption after unexpected machine power off.
- Backup Repositories can be attached and detached. This feature allows you to preserve the data in a consistent state, copy repository files to another location, etc. It can be done manually or on schedule. When a Backup Repository is detached, the NAKIVO solution stops interacting with this repository and its files.
- An attached Backup Repository is operated by a Transporter, is considered to be fully functional at a given moment, and can be used by jobs.
- A detached Backup Repository is not operated by a Transporter and cannot be used by jobs. It can be moved or disconnected while detached.
It is impossible to run maintenance manually or on schedule when a repository is detached.
It is recommended that you run operations that consume CPU resources (for example, space reclamation and backup repository verification) during non-business hours, such as at night or over weekends. A CPU on the machine with a Transporter assigned to the appropriate Backup Repository is used for these operations.
Recovery Point Immutability
Backup repositories on certain media and platforms support immutability for backups. Immutability prevents data from unwanted changes, encryption, and deletion, which makes recovery points immune against ransomware and other cyber threats. This technology relies on the Write Once Read Many (WORM) technology.
Immutability should be enabled for a backup in the job creation wizard. It can be enabled for recovery points stored in the following supported Backup Repository types:
- Local Folder on the assigned Transporter for backup repositories on Linux
- Repositories in Amazon S3, Wasabi, Azure Blob Storage, and Backblaze B2
- Other S3-compatible storage platforms that support Object Lock and version-level immutability
When using Backup Repositories like Amazon S3, Wasabi, Azure Blob Storage, Backblaze B2 Cloud Storage, and other S3-compatible storage platforms, you should enable Object Lock or version-level immutability support for the bucket or blob container responsible for storing backups. This immutability feature ensures that data cannot be altered or deleted, even by the root user and it cannot be shortened or lifted once enabled.
When utilizing the Local Folder type of Backup Repository, immutable recovery points are protected from being overwritten, deleted, or modified by anyone other than the root user until the specified period elapses.
Upon deploying the Local Folder type of Backup Repository as an integral part of VMware vSphere (from the OVA template) or a pre-configured AMI in Amazon EC2, NAKIVO Backup & Replication offers an enhanced level of ransomware protection. This involves the option to make recovery points stored within this repository immutable, meaning they cannot be altered or changed by anyone, including the root user, once the immutability feature is enabled.
Backup Repository Structure
A Backup Repository has a special structure to store backup data and you cannot find traditional files, such as virtual disks, in the directory of a Backup Repository (NakivoBackup).
Important: Don’t change or delete any files or folders of a backup repository manually.
- Backup folders: Each folder contains the recovery points for any given backup job.
- Raw folder: Contains raw data files (Chunk files). Chunk files format: index.variant(0000.001, 0001.002, 0002.00a, 0003.00b, …).
- Descriptor files: Storage information of all Chunk files in the repository:
- + RawBlockRecord (include flags, variant, length, offset, hash1, hash2, rcount): The information of a block in the descriptor file.
- + ShiftBlockRecord (variant_old, offset_old, variant_new, offset_new): The information of a block that is changed from the old position to the new position in the raw data files.
- + ChunkMap: storage information of chunk files (The same chunk index, different variant) and the descriptor files will contain a list of ChunkMap, which is loaded when initializing the repository.
The lock file is used to prevent using a Backup Repository by two Transporters simultaneously.
The logical structure of the Backup Repository is as follows:
– Backup Repository
- Backup 1
- Recovery Point 1
- Recovery Point 2
- Etc.
- Backup 2
- Recovery Point 1
- Recovery Point 2
- Etc.
Recovery points are automatically deleted when their retention period expires (based on the expiration dates set or on the legacy retention method in versions 10.7 and earlier). You should not delete any files manually from the directory of the backup repository.
How to Create a Backup Repository
You can create a new Backup Repository in NAKIVO Backup & Replication on any of the supported platforms that were listed above.
Let’s create a new Backup Repository on a machine with Ubuntu Linux installed. The main requirement to create a new Backup Repository on a remote machine is a Transporter installed beforehand on that Linux machine. We have a Transporter already installed on this Linux machine.
We use these two machines for the deployment and configuration of the NAKIVO solution in this example:
- NAKIVO Director (full solution): 192.168.101.209
- NAKIVO Transporter on a Linux machine: 192.168.101.210
If the Transporter is installed, perform the following steps to create a new Backup Repository on a Linux machine:
- Create a directory that will be used for the new Backup Repository to store backups. We create a directory called repository1 in /opt/nakivo/ and go to this directory in the Linux console:
cd /opt/nakivo/sudo mkdir repository1 - Set the NAKIVO user, which is called bhsvc as the owner of this repository1 directory (you need root privileges to perform this action):
sudo chown -R bhsvc:bhsvc repository1Note: If you create a Backup Repository on NAS, to set the NAKIVO user as the owner of the repository directory, use:
sudo chown -R u_bhsvc:g_bhsvc repository1 - Set the right permissions for this directory to make it possible to read and write backup data by the NAKIVO solution:
sudo chmod 0775 repository1 - Check whether the owner and permissions have been set by checking the contents of /opt/nakivo/:
ls -al
- A directory is created and configured. Now open the web interface of NAKIVO Backup & Replication (provided by the NAKIVO Director component). The link we open in our web browser is https://192.168.101.209:4443 in this case.
- Go to Settings > Repositories, click +, and click Create new backup repository.
- The New Backup Repository Wizard opens.
- Select a Backup Repository type at the first step of the wizard. As we are creating a new Backup Repository on a Linux machine, we select Local Folder. Hit Next to continue.
- The second step requires setting a name and location. Enter a Backup Repository name, for example, RepositoryL1.
Select the assigned Transporter for this Backup Repository. We select the Transporter installed on the remote Linux machine (192.168.101.210).
Enter the path to the local folder on the machine where the Transporter is installed. This directory is /opt/nakivo/repository1 in our case, which is the directory we created on our Linux machine.
Click Next to continue.
- Configure options. At this step, you should configure storage savings, encryption, reliability, and maintenance options for the Backup Repository. If you want to use compression, set the data size reduction options now at this step. You cannot change compression settings for a Backup Repository after the repository is created.
If you want to create a forever-incremental backup repository, click Settings at the Data size reduction line and deselect the Store backups in separate files (recommended) checkbox. Click Apply.
- A new Backup Repository has been created.
You can click a Backup Repository (the list of repositories is located in Settings > Repositories) to view used sized, free size, and other Backup Repository parameters.
You can hover the mouse on the Backup Repository name and click the three dots icon to open a menu with actions that you can do with the selected Backup Repository. You can recover data, edit some repository settings, verify backups, repair a Backup Repository, run repository self-healing, etc.
Enabling immutability
If you want to store immutable recovery points in a Backup Repository, you should enable the immutability when creating a new backup job (click Jobs, hit + to create a new backup job, and select what you want to back up). A Backup Repository created on a Linux machine (which is our case) supports immutability.
At step 3 of the new backup job wizard, where scheduling and retention settings are configured for a backup job, you can find the immutability settings. Select the appropriate checkbox and the number of days to make the backup immutable for that number of days.
