Forever incremental discontinued?

[Jim]

Has forever incremental repository type been discontinued in the latest versions?

I don't see the option when creating a new repository.

I know that forever incremental comes with the annoyance of having to do space reclaims but there is still a use case.

Eg. For doing large backups across a WAN connection. There would be bandwidth issues with doing a weekly full backup across a WAN connection.

[Official Moderator]

Hi, @Jim!

In a new release (version 10.4), we have updated the UI for the Repository screen. The repository type menu was removed. The "Store backups in separate files" option was added (enabled by default). Backup repositories created in previous versions of the product keep operating in the way they were configured.

Background: Storing backups in separate files is recommended.

• Downside: it has higher space requirements.
• Upsides: it is more resilient to network, power, and hardware failures; it does not require running space reclaim; it is suitable for enterprise-grade deduplication storage devices; it supports immutable recovery points.

Solution: If you still want to use the "forever incremental" repository and built-in data deduplication, please uncheck the "Store backups in separate files" checkbox when creating the backup repository.

If you need any further information, please don't hesitate to contact me.

[TonioRoffo]

But why this change, though?  Is your deduplication storage that prone to errors?  For me, it seems this way of storing data is efficient and a major selling point for Nakivo.

[Official Moderator]

2 hours ago, TonioRoffo said:

But why this change, though?  Is your deduplication storage that prone to errors?  For me, it seems this way of storing data is efficient and a major selling point for Nakivo.

Hello, @TonioRoffo I communicated with our Support Team and they answered the change was made because a lot of our customers highly requested it. Furthermore, the repository with deduplication can be created without any issues. We look forward to hearing from you if you have more questions. Thank you for understanding.

[Ottavio Passoni]

On 6/28/2022 at 2:17 PM, TonioRoffo said:

But why this change, though?  Is your deduplication storage that prone to errors?  For me, it seems this way of storing data is efficient and a major selling point for Nakivo.

I'm perfectly agree with TonioRoffo and Jim. Deduplication efficiency and incremental forever has been, from the beginning, one of the main reasons that made me choose Nakivo as the number one backup solution for my customers. The obligation to periodically perform full backups was, for some of my customers, extremely boring for obvious reasons of time and space consumption. Now I find myself having to destroy the repositories with all my backups to recreate them with the correct settings in order to be able to use them in "incremental forever" as I was always used to on previous versions from Nakivo. I think the change was indeed a bad idea.

[Official Moderator]

15 hours ago, Ottavio Passoni said:

I'm perfectly agree with TonioRoffo and Jim. Deduplication efficiency and incremental forever has been, from the beginning, one of the main reasons that made me choose Nakivo as the number one backup solution for my customers. The obligation to periodically perform full backups was, for some of my customers, extremely boring for obvious reasons of time and space consumption. Now I find myself having to destroy the repositories with all my backups to recreate them with the correct settings in order to be able to use them in "incremental forever" as I was always used to on previous versions from Nakivo. I think the change was indeed a bad idea.

@Ottavio Passoni, your information/request has been received and forwarded to our Level 2 Support Team.

Meanwhille, the best way for both sides would be to generate and send a support bundle (https://helpcenter.nakivo.com/display/NH/Support+Bundles) to support@nakivo.com so our Technical Support team can investigate it and forward your feature request to our Product Development team for possible future implementation.

We will follow up with you shortly. 

[Official Moderator]

22 hours ago, Ottavio Passoni said:

I'm perfectly agree with TonioRoffo and Jim. Deduplication efficiency and incremental forever has been, from the beginning, one of the main reasons that made me choose Nakivo as the number one backup solution for my customers. The obligation to periodically perform full backups was, for some of my customers, extremely boring for obvious reasons of time and space consumption. Now I find myself having to destroy the repositories with all my backups to recreate them with the correct settings in order to be able to use them in "incremental forever" as I was always used to on previous versions from Nakivo. I think the change was indeed a bad idea.

Hello @Ottavio Passoni For now, it is still possible to create "Forever incremental" and "Incremental with full" types of repositories in NAKIVO. The only changes that were implemented in NAKIVO - are the default settings in which the repository is created.

Previously that was "Forever incremental". Now it is "Incremental with full". Configuring repository type is done with the "Store backups in separate files" checkbox during repository creation.

With the checked "Store backups in separate files" box, there will be created "Incremental with full" repository type. With unchecked "Store backups in separate files" box, there will be created a "Forever incremental" repository type.

We look forward to hearing from you.

[Leslie Lei]

I think the developer made a fundamental mistake here.  The repository should be only responsible for storage type (Disk or tape), where the data is stored (local, NAS or cloud), and how the data is stored (Compression and Encryption).   The backup job should determine how the data is structured.  "Forever incremental" and "Incremental with full" options should be within the job schedule section, and the retention policy determines how long the data should be kept.  To determine if the data "Forever incremental" or "Incremental with full" should be the function of the backup job itself, not the function of the repository.

[The Official Moderator]

On 11/10/2023 at 8:44 PM, Leslie Lei said:

I think the developer made a fundamental mistake here.  The repository should be only responsible for storage type (Disk or tape), where the data is stored (local, NAS or cloud), and how the data is stored (Compression and Encryption).   The backup job should determine how the data is structured.  "Forever incremental" and "Incremental with full" options should be within the job schedule section, and the retention policy determines how long the data should be kept.  To determine if the data "Forever incremental" or "Incremental with full" should be the function of the backup job itself, not the function of the repository.

@Leslie Lei Thank you for your valuable contribution to the NAKIVO Forum. Your insightful post has been duly noted and has been forwarded to our esteemed Product Development team for thorough consideration.

Such requests hold significant weight in shaping the future of our product, and we are committed to exploring its feasibility for potential implementation.

[The Official Moderator]

On 11/10/2023 at 8:44 PM, Leslie Lei said:

I think the developer made a fundamental mistake here.  The repository should be only responsible for storage type (Disk or tape), where the data is stored (local, NAS or cloud), and how the data is stored (Compression and Encryption).   The backup job should determine how the data is structured.  "Forever incremental" and "Incremental with full" options should be within the job schedule section, and the retention policy determines how long the data should be kept.  To determine if the data "Forever incremental" or "Incremental with full" should be the function of the backup job itself, not the function of the repository.

@Leslie Lei Thank you for your patience. Unfortunately, it is not currently possible to configure "Forever incremental" and "Incremental with full" options within the same job schedule. This is because they are two completely different types of repository. However, we appreciate your feedback and have filed a feature request for this capability. We will consider it for implementation in future releases based on customer demand and other factors. In the meantime, please let us know if you have any other questions or concerns.