Separate repo for "archived" users?

[pufferdude]

We have two use cases for VBO... 1. Routine backups for recovery of lost data for current users, and 2. Archival of staff that have left employment, but we want to retain access to their email/files indefinitely.

For #1 we want to use a snapshot style backup and keep two years of snapshots. For #2, it seems like to accomplish this archival need, we'll need to have a DIFFERENT repo that has no retention period, and then when staff leave we make a special (new) backup for their files/email to that repo, and after we delete their user out of O365 and 31 days have passed, they will no longer consume a license, but will have recoverable archives.

Is that accurate and worth doing? Or are we crazy for trying to keep this data indefinitely within VBO and should instead just export the files and email (to PST, I guess?) to an archival file system? Is anyone else doing what we're suggesting?

[JRRW]

That's a great question.

In practice, the way we handle this is starting to slip into gray areas within Microsoft's licensing.

Our current procedure is:

1. Convert user to Shared Mailbox
2. Daily powershell script (or can be done manually) removes user from 'Active' users backup and into 'Shared Mailbox' backup in VBO
3. Next run the shared mailbox is now under that job

We use Shared Mailboxes because 'technically' they are free both for O365 and in Veeam. However Microsoft is starting to narrow this, with requiring licensing for Shared Mailboxes using Archives over a certain size, and very likely they might further this limitation. Long term I agree that the better route would be to do something like a backup during the time you leave their account 'active' and once it's removed, also remove it from the VBO job. This should not remove the data from the repository.

Now, we currently use the same repository for both - this is a huge time saver as we don't need to 'migrate' the data between and/or re-download the entire users mailbox + Archive again into a new repository - but VBO allows us to also handle this via PS with a Move-VBOEntityData which can be i/o intensive, but may be better than re-downloading if you've large data and low bandwidth.

Counterpoint: This is also why our current repositories for Mailboxes is over 80TB and guess what doesn't like being over 64TB? You guessed it - VHDX's! So you know, don't virtualize if you're that big. Also in general, Object storage is soooo much better for VBO.

Important Note
You can move from Local -> Local or Local -> Object (S3) but you cannot do Object -> Object or Object -> Local - so keep that in mind.


I hope this helps you!

[Mike Resseler]

@pufferdude

You are not the only one with such a type of requirement, the only difference I see is that most organizations that want to keep data for their employees that left (whatever reason) is the same retention as their active employees. That is the thing in your requirement that I find a bit strange to be honest. Employees that remain with the company for many years will have less data recoverable then employees who left 10 years ago or something like that

By the way, if you go the object storage route, then indeed you will have a backup copy possibility in vNext (soon to be released) that will allow you to create a copy of the data to another repository (low-cost object storage in the cloud) with a different retention.

[pufferdude]

I see what you're saying, and maybe we ARE thinking about this wrong, but what we were trying to do is find a balance between data recovery and every-growing storage. Our thought process was along the lines of...

- The daily 2yr retention backup for all current staff is for DR recovery of files, as well as having the ability to go back in a *reasonable* timeframe to find something the user deleted long ago. We've never backed up (and kept) "every file every user ever created" so didn't think we needed to with O365 data, either. Keeping a snapshot of their *current* file/email state and being able to go back 2yr seems reasonable.

- But for EXITING staff, we want to keep a snapshot of their environment the way it was when they left, thus we can't let them live (once they exit) in the 2yr retention repo or their data will start evaporating after the threshold is reached.

Again, that could be completely wrong thinking, but that's what led us to this question. We simply can't keep every file (or email) every user has ever created/sent/received because we can't afford open-ended storage.

[Mike Resseler]

So you kind of want 1 snapshot of that user (last "backup") with no retention.

[pufferdude]

That's exactly what I'm trying to achieve

[Mike Resseler]

A workaround (but not the best one, I am aware of that) is to create a job pointing to a repository with no retention. Each time a user leaves, get the user out of the primary job. Put him temporarily into that job pointing to the retention-less repository and then run the job manually. That way, you always have the latest snapshot, only once, and forever

[pufferdude]

Thanks! That's exactly what I described on my initial post here Was just looking for confirmation if that was a sane thing to do, or Bad Idea(tm) for some reason I wasn't thinking of. Thanks for the feedback! For better or worse, we're proceeding along this path.

[Stabz]

Hello,
Seems that I m not the only one who need to backup mailboxes for staff that have left the company.

I had the same idea to create a second Job, but this involve to implement somes process and it's time consuming espescially if the actions are made manually. It could work for a small compagny...but with thousand of users it's not conceivable.

Maybe there is a way to automatism this action with some powershell script but unfortunatelly I m not an expert in this domain.

Therefore I created a backup for VBO server with Veeam Agent, and I archive this backup with GFS points. It's not optimal in terms of used storage space but with this solution I protect my VBO with the 3-2-1-1-0 rules.

[pufferdude]

Where we landed was to not run a separate job to an archive repo, but to just have an archive repo (with forever retention policy) and then after the departed person's last normal backup, we run Move-VBOEntityData to move the user's data from our 2yr retention repo to the archive repo (I made a script with source and destination repos baked in, and prompts for user's name then runs the move).

Like you said, it doesn't scale, but we're a small 140 staff company and it's manageable with our churn rate.

[hbilke]

Ave collegae

---
Our current procedure is:

1. Convert user to Shared Mailbox
2. Daily powershell script (or can be done manually) removes user from 'Active' users backup and into 'Shared Mailbox' backup in VBO
3. Next run the shared mailbox is now under that job

...
So a user mailbox stays "user" after having been change to "shared"? And what is in the PS-script?

hRy