Jump to content
NAKIVO Backup & Replication v10.10 Beta is now available for testing! ×
NAKIVO Community Forum

Can I get an update on new repo which offers online space reclamation?


Recommended Posts

A few months back, I was told by support that a new type of repository was being developed where space reclamation could run without blocking access to the repo. The process would be similar to how a Data Domain can run space reclamation while still accessible but at the expense of I/O performance; however, reclamation can be throttled to increase I/O performance at the expense of running a longer reclamation period. Is it possible to get an update as to the status of this technology?

I run backups nightly and need to reclaim space after each run due to storage space constraints. I've designed my job calendar to maximize the reclamation time period, but it sometimes runs into the next day's schedule. While normal backup jobs will pause reclamation, the director backup will fail if it is running. While my systems often run without incident, the Director can be chatty with its alerting which reduces the effectiveness of bringing important events to my attention.

  • Like 1
Link to comment
Share on other sites

Hello, @cmangiarelli

Thank you for your interest in NAKIVO Backup & Replication!

Please note that our Development Team is actively working to add the new repository type in the upcoming releases. Currently, there is no ETA, but this feature is the top priority for us. 

As for the space reclaim process, could you please clarify why you need to run it so often? 

Link to comment
Share on other sites

It's certainly nice to hear it is in development, but hoping it will come sooner rather than later.

Regarding the frequency of reclamation, as I said in my original post, we have space constraints to deal with. Our old backup application was scheduled to back up VMs weekly, but we would backup SQL databases nightly. Since Nakivo has no "agent", we have to back up the entire VM nightly; yeah we could create a job for the drives containing SQL, but that is where most of the change occurs anyway, so we keep it simple. We actually prefer the simplicity of the scheduling now and the nightly backups of entire VMs, but the testing of Nakivo in our lab didn't accurately predict the dedupe ratio's we would see in production. Separate backup storage is not available in some of our smaller, shall we say fiscally-challenged, environments so the repo is placed on local SAN and then replicated off-site. The amount of available SAN storage is limited, and with the slightly lower than expected dedupe ratios, we get close to running out of repo space after a few days if we don't run reclamation after our backups. We have SLAs around retention, so I'm keeping the bare minimum.

As was mentioned in a diffent thread, the reclamation process reclaims a good portion of the available space early on in the process. Thus, with my current scheduling, I get a very good return on my reclamation period even if it gets interrupted by the next day's backup scheduling.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...