Subject: | |
From: | |
Reply To: | |
Date: | Thu, 30 Jul 2015 10:09:16 -0600 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Larry notes one of the more significant issues with using file shares -
file paths can become excessively long very quickly, especially in
combination with a naming convention like
YYYYMMDD_this_that_tother_owner_user_version.doc. SharePoint has the same
potential issues btw.
More importantly to me, file shares are problematic from an access control
perspective. It's a lot like work to get the file share to understand the
nuances of what is typically required from a retention perspective and to
ensure that information can be managed throughout the lifecycle. And file
shares are not particularly rich in metadata or in the ability to search
without leveraging some other tool (and therefore defeating the purpose).
This just jumped out at me, though. "If you keep permanent backups..." Eh?
Why on earth would any organization do this?
But that entire paragraph is bad. Yes, backups could be used in litigation
(and I am not a lawyer by any stretch) but pretty sure the current approach
in the FRCP is to treat backups as inaccessible unless there is a specific
reason to look to them such as spoliation. Every organization of any
size/complexity uses "rolling" backups - I think meaning periodic full
backups with partial, incremental, and differential backups more
frequently. I'm OK with including backup disposal in the RRS somewhere,
albeit not never ever under any conceivable circumstances as permanent, but
I don't think noting when particular data will "roll off" is that helpful.
My tuppence on a gorgeous Colorado morning,
Regards,
Jesse Wilkins, CIP, CRM, IGP
[log in to unmask]
blog: http://informata.blogspot.com
Twitter: http://www.twitter.com/jessewilkins
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|
|
|