Many organizations are using SharePoint sites for managing information including company Records. Sites have a maximum size limit and users commonly delete Transitory Records (convenience copies, prior versions, etc.) and move Records to record keeping systems (e.g., we use FileNet). When a record preservation hold is put in place for litigation holds, or to respond to regulatory, privacy or other requests that require e-discovery, all information must be kept which mean the SharePoint site size gets to large. I am referring to SharePoint sites used for collaboration site, and external transmittal/submittal portals. I would appreciate hearing from people experience this challenge and how you are addressing it including any tools (including e-discovery tools) or software used to manage the Records.
Just out of curiosity, how large your sites are?
I can share my thought on this but most likely you have considered this option already. Also, as usual with SharePoint there are too many – it depends.
Depending on your environment and content lifecycle you might be able to challenge some of the SharePoint limits. Partially, ‘size’ limitations (or recommendations) are in place to support native SharePoint backup/restore operation of content databases. I can see how 3 hours of native/SQL database restore violates service RTO. However, the same job can be done in minutes using backup solutions based on storage snapshots. We had 300GB (vs. 200GB limit) content databases supporting collaboration sites in the past, with no e-discovery running though.
In the event of a legal hold the information does have to be retained however you can copy the information to a different environment. You just have to establish that the copy is in fact complete. You will have to establish a defensible legal hold process and test it. Audits of your own legal hold process will prove it credible and allow for you to keep your sites manageable.
I’m a bit confused. You mentioned you use FileNet yet your question is about managing records in SP. Why are you not using Enterprise Records in P8? I’m making the assumption you have P8 and SP integrated via the connector? If so, why do you have an issue? If you can provide some additional context it might help.
We use Remote Blob Store (RBS) through the use of Metalogix StoragePoint to keep the content in an encrypted file system while the content database stores the metadata. This keeps the content database sizes under 200 GB for our scenario. The StoragePoint product has its own hold mechanism if you need to do in-place holds. We however create pristine copies using the eDiscovery Center.
AEGIS Insurance Services, Inc.
Hi, Unfortunately RBS doesn’t help to overcome size limits. As per MS – “If you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed the 200GB limit.”. This is for general usage scenarios. Under certain conditions up to 4TB databases are supported (SharePoint 2016). I’m very interested to hear how others deal with constantly growing volume of content too. Adding more disk space doesn’t always solve the problem.
Hi, I’m not the expert. My understanding is that it is the suggested content db size is only applicable if SharePoint’s native back up and restore features are being used/relied on. If you have a 3rd party backup and restore application for SharePoint the 200GB soft limit is thus not a hard limit. I suggest you do more research on what the 200GB limit relates to.
Remember BLOB storage is not meant for big volumes of relatively small files, but rather meant for big file sizes like architect files (think it’s called CAD files). So if you plan high volume document and records management in SharePoint for relatively small files sizes I would rather look at a proper back-up and restore application. We use Catalogic which even allows granular restores.
Getting to above info when researching is unfortunately not easily to find, similar to the 5000 list view threshold (LVT) misunderstanding making people believe a library can only house 5000 documents. Where in fact it can house millions, the 5000 is just a soft limit to limit the impact on SQL when the view parameters query SQL. Lucky this has been improved/removed in SP 2016.
Happy for the forum to validate the above comments. Kind regards
The discussion is veering off into an SP architecture realm. Not exactly what was originally asked.
Again, if Rosa could provide some additional context/details around the RECORDS MANAGEMENT issue she asked about?