Selective delete from NAS

[poulpreben]

Hi all. is there any way to selectively purge data from a NAS backup without lowering the overall retenton?

The NAS retention is currently configured for 72 months, but we would like to remove a portion of that dataset (we discovered some relatively large SQL dumps). Another use case, which we have not come across yet, is being able to delete PII in a dataset.

With a normal VM or agent backup, we would use the "delete from disk" option, but with NAS that would remove the entire NAS backup and history.

What would be the best way to go about this?

[Dima P.]

Hi Preben,

The only option would be to change the retention. Cheers!

[poulpreben]

Hi Dima,

Thanks for the confirmation. Can you please consider this a feature request then?

[nitramd]

+1 for Preben's FR.

[Dima P.]

To clarify: you want to remove all the content related to the specific restore point (i.e. select the restore point and remove it) or you want to remove the specific data without removing other restore point content? Cheers!

[poulpreben]

Takling about restore points for NAS backups is probably a bit confusing. The outcome should be that I am able to purge a specific path from all backups between date X and Y.

[Dima P.]

Got it, thanks for the clarification.

[poulpreben]

...and today it happened Did you have the chance to discuss if this is something that will be implemented in an upcoming version?

[Dima P.]

Preben,

The upcoming version has been fully packed before this discussion started, so we will get back to this request review for future releases only.

Thanks!

[markK]

Hello,

I am getting started with Veeam B&R and hope to use it to backup my NAS.

But I have one question regarding how to delete files or folders from a backup repository. For example, suppose that some filetypes - or a whole folders - have been saved to a backup repository, and I later realise that these should be removed, then how can I go about doing this?

I have tested adding file or folder exclusions to a backup job, but this does not remove the files/folders that have previously been saved to the repository, only excludes new files going forward.

There is a similar post from 2020, but I don’t see any further updates since then:
file-shares-f57/selective-delete-from-nas-t66006.html

Appreciate any help on this!


Cheers,
Mark

[HannesK]

Hello,
and welcome to the forums.

There is a similar post from 2020, but I don’t see any further updates since then:

the reason is, that everything is still the same for this feature request.

For example, suppose that some filetypes

can you maybe provide examples when this is useful? I have some ideas in mind, maybe my ideas are different from yours.

and I later realise that these should be removed

as many customers are for immutability of backups, I ask myself how these things fit together

Best regards,
Hannes

[Dima P.]

filetypes - or a whole folders - have been saved to a backup repository, and I later realise that these should be removed, then how can I go about doing this?

If the file or folder is removed from the file system and nas job will track that and remove such items from the backup after such file in the backup is expired in terms of retention.

[markK]

Hello Hannes, hello Dmitry,

Thanks for updating the status of the request.

A bit of background. I run a small studio; the NAS is our file server for sharing files between colleagues.

Filetypes: I can think of two scenarios. Scenario 1: I am an idiot and forget to include file exclusions when I set up the backup job - system, hidden, temp files. Scenario 2: My colleagues start using a new software, which wasn’t invented when I was at school; this leaves autosave, temp, lock, cache files etc in our project folders. Yes, these are probably small files to keep in a repository, so I live with it. Then, the other question is what if I want to remove whole folders?

Folder example: Our client sends us a bunch of huge files for a project. These are included in our backup job, but later the project changes and those files are irrelevant to us. I delete the folder from my NAS, but the data stays in my backup repository until removed by retention policies. If the retention for my backup is set to 10s of years, then I keep and pay for unwanted files. Or, I lower the retention to remove these files, but I may lose other files that I may have wanted to retain.

Having the flexibility to remove certain data (files or folders) from a repository seems reasonable to me. If my concepts on backup are flawed then I’m happy to be educated!

[HannesK]

for different retentions and use-cases I would use different folders on the NAS and different jobs in VBR. the idea of deleting parts of backups sounds weird to me... if I want to save something for 10 years then there must be a reason for that. With jobs "per customer" / "per project" I could just delete all data of that job "now" if I want.

What you ask for works with sync-tools like rsync. but for backup tools it sounds like the wrong approach to me (we can agree to disagree on that ).

[markK]

What if files or folders are saved to a wrong location through human error? How can I remove them from a backup without changing the retention settings or deleting an entire backup job and all it’s history?

That’s what I would like to be able to do.

[Dima P.]

Thank you for updating the thread! The situation when file is moved is treated the same way as when file is deleted: backup will keep the file version for the set amount of days in the retention property, then removes it according to the retention. With such logic you will have some extra space consumed by the backup file but the issue itself will be resolved itself as soon as retention kicks in.

[markK]

Thanks for explaining how moving files is handled. In my situation I plan to use an indefinite retention period. If I understand correctly, then deleted or moved files would never be removed from the backup. Then the problem is there is no way to force a purge - for whatever reason - of unwanted files from the backup. Please include my support for this feature request!

[soncscy]

I think you've accidentally stepped into a user-class war here, Mark K

Your point and use case is absolutely valid, and the fastest workaround I can recommend is plan the jobs a bit more carefully; the appeal of a single job is understood, but it forces you to try to fit a single backup scheme to all your data, and not all data is equal as you are experiencing. Setting Job Tiers for your data on the NAS and a default retention accordingly is your best bet.

As for why I say "user-class" war, it's because you have two ends of the spectrum when it comes to backups:

"I should be able to control and delete anything inside the backup at any time, I'm a smart user and I know my business needs better than you"

"Holy crap, what do you mean any admin can change retention or delete backups? Backups must be immutable! What good are they if I have to constantly check that everything is okay?"

From my experience with clients, smaller businesses or businesses on a budget tend towards the first side, because space and personnel bandwidth is limited, so being able to free up space on the fly is a must while keeping the environment manageable (e.g., not 100+ jobs)

Larger business that are subject to stricter regulations want the latter, and don't want to have a dedicated admin watching and checking that nothing has changed, and more importantly, they want such assurances "out of the box", so scripting is typically a no-go.

I don't see a lot of cross-over on these two, as the goals are completely opposite; the reason I think a lot of vendors tend towards the latter (besides $$$$ that these clients bring) is that the request of the former can "usually" be honored by just more jobs to accommodate for the data you work with.

For what it's worth, I fall towards the latter; I really need to be sure that once something is backed up, it stays there, and editing backups is a real scare for me. I've seen other vendors that allow this, and, well, I've seem some scripts where someone put *>extension instead of *.extension, and it was a real moment when we went to restore...this is just one example of an "innocent" mistake leading to backup death. I'd hate to see what a malicious action might look like.

[markK]

Hello Harvey,

You summed up my position well, and at the same time I understand why larger businesses insist on backup integrity above all else.

Thanks for your suggestions; I do plan to create few jobs according to different retention requirements.