-
- Service Provider
- Posts: 37
- Liked: 4 times
- Joined: Mar 12, 2019 10:20 am
- Full Name: Dan Kennedy
- Contact:
Reclaiming disk space
A customer has asked for us to exclude/remove a number of users from their backups as it's getting too expensive for them!
I ran a powershell script to remove all backup data for around 100 users (mailboxes, OneDrive, Sharepoint etc.)
This should have removed hundreds of GB's of data....but the size of the repository has not changed?!
Could anyone tell me how I can reclaim the actual disk space now the data is gone?
Have we just created whitespace in the databases which Veeam uses in the background? Can that be cleaned up at all?
I ran a powershell script to remove all backup data for around 100 users (mailboxes, OneDrive, Sharepoint etc.)
This should have removed hundreds of GB's of data....but the size of the repository has not changed?!
Could anyone tell me how I can reclaim the actual disk space now the data is gone?
Have we just created whitespace in the databases which Veeam uses in the background? Can that be cleaned up at all?
-
- Product Manager
- Posts: 5797
- Liked: 1215 times
- Joined: Jul 15, 2013 11:09 am
- Full Name: Niels Engelen
- Contact:
Re: Reclaiming disk space
Correct, we will re-use the allocated "freed" up space. Shrinking files won't happen when you remove data via Powershell. I believe space can be cleaned up but I do suggest to involve support if you want to do this.
Personal blog: https://foonet.be
GitHub: https://github.com/nielsengelen
GitHub: https://github.com/nielsengelen
-
- Service Provider
- Posts: 24
- Liked: 10 times
- Joined: Nov 23, 2017 7:20 am
- Full Name: Jacob Palm
- Contact:
Re: Reclaiming disk space
I have previously had a support case regarding this, where we were told that no automatic cleanup was done. This was back around April-May, so I'm not sure if this still applies to more recent versions.
I understand that this is due to the database format used, but I still think some sort of automatic cleanup should be put in place. There's potential for huge amounts of wasted space, not only when manual deletion of data is performed, but also during day-to-day application of retention policy. Especially with large organizations, or service provider servers containing many organizations.
As an example, we had a customer with an almost empty database from 2018 which was entirely out of retention, but the database was not shrinked or removed automatically. Sitting there, it wasted more than 100 GB.
Again, this was back in the beginning of the year, so if something has changed since then, I'd be happy to know.
I understand that this is due to the database format used, but I still think some sort of automatic cleanup should be put in place. There's potential for huge amounts of wasted space, not only when manual deletion of data is performed, but also during day-to-day application of retention policy. Especially with large organizations, or service provider servers containing many organizations.
As an example, we had a customer with an almost empty database from 2018 which was entirely out of retention, but the database was not shrinked or removed automatically. Sitting there, it wasted more than 100 GB.
Again, this was back in the beginning of the year, so if something has changed since then, I'd be happy to know.
-
- Product Manager
- Posts: 8191
- Liked: 1322 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Reclaiming disk space
Jacob,
The underlying database is a JET DB (also known as Exchange DB so cleanup of the database is not something that is done automatically.
We do reuse the space as Niels said. And I do wonder, because when a database of 2018 is literally out of retention (which means it should not contain any item anymore) then the jet DB should be removed automatically.
The underlying database is a JET DB (also known as Exchange DB so cleanup of the database is not something that is done automatically.
We do reuse the space as Niels said. And I do wonder, because when a database of 2018 is literally out of retention (which means it should not contain any item anymore) then the jet DB should be removed automatically.
-
- Influencer
- Posts: 14
- Liked: 3 times
- Joined: Jun 28, 2021 1:35 pm
- Full Name: Fredrik Kristensen
- Location: Norway
- Contact:
Re: Reclaiming disk space
I hope it's okay that I add to this thread. We are in the process of implementing VBO and from my little testing it seems that the situation is unchanged in 2023, that is that free disk space is not reclaimed.
Let's say someone by accident completely fills up the repository. Either by poor planning or misconfiguration of jobs and retention. One can remove all the data with Remove-VBOEntityData, but that will not actually free up any space on the repository. We then have a repository that is permanently completely full, correct? Are there any plans to implement a cleanup feature in the future? In severe cases, does Veeam Support have any ways to reclaim disk space?
Are there any plans for the future to allow VBO to use an external database (MS SQL or PostgreSQL) instead of the embedded Jet DB? Similar to what VBR has today.
Let's say someone by accident completely fills up the repository. Either by poor planning or misconfiguration of jobs and retention. One can remove all the data with Remove-VBOEntityData, but that will not actually free up any space on the repository. We then have a repository that is permanently completely full, correct? Are there any plans to implement a cleanup feature in the future? In severe cases, does Veeam Support have any ways to reclaim disk space?
Are there any plans for the future to allow VBO to use an external database (MS SQL or PostgreSQL) instead of the embedded Jet DB? Similar to what VBR has today.
IT adviser
Virtualization, Storage and Backup
Virtualization, Storage and Backup
-
- Veeam Software
- Posts: 3195
- Liked: 774 times
- Joined: Oct 21, 2011 11:22 am
- Full Name: Polina Vasileva
- Contact:
Re: Reclaiming disk space
Hi Fredrik,
1) We are not planning to add any cleanup for Jet-based repositories. The full focus is on object storage and it will continue to get more and more new features.
2) Veeam support can assist with shrinking the repository database
3) External databases will come but they are not going to be used for storing backups. They will help to achieve better scalability and performance.
Thanks!
1) We are not planning to add any cleanup for Jet-based repositories. The full focus is on object storage and it will continue to get more and more new features.
2) Veeam support can assist with shrinking the repository database
3) External databases will come but they are not going to be used for storing backups. They will help to achieve better scalability and performance.
Thanks!
Who is online
Users browsing this forum: No registered users and 24 guests