On Thu, Sep 6, 2012 at 12:20 PM, David Parter <[email protected]> wrote:
> From a user point of view, they would specify a collection of > files/directories (most likely an entire project area in the file > sytems) and ask that it be archived under some naming scheme, for a > specific period of time (at which point notification is sent to do > something -- extend the archive expiration date or delete the archive, I > don't know). > > From a technical point of view... I don't know what the requirements > are. Obviously, we want to preserve the data. I am sure others have > already come up with requirements and solutions to avoid, detect and > hopefully correct bit rot... If you are archiving a project, you may well need more than just the data- What software package(s) are used for working with the data. Given a long enough retention period, you'll need to note those and possibly include them in the archive. If the applications have specific patch levels, you'll need those too. What about license keys for the applications given that many are only good for a limited duration instead of forever? What about host ids (or whatever the vendor uses for node locking)- do you have a way to recreate them? What about generic environmental things (office apps for reading files, for example; or shells and dot files; or your departmental configuration management software) What about the OS (including patch level(s))? One tool I used in a previous job was very finicky about patches on Solaris. If you had the wrong X server patch (it typically was a range of "incompatible with revs xx, yy-zz, etc.), it wouldn't work well if at all. What about hardware to run the applications- if you retire all the Sparc/HP-PA/RS6000 hardware and the project was written on it, all the bits in the world are not going to help you How about hardware to read the media (both tape/optical/whatever drives, and a computer that they can be attached to)? While I never ran into it, even "simple" things like changing usernames, UIDs, IPs, domain names, etc. due to a change in company policies could have side effects that fatally break stuff (or at least require more time to reverse engineer) Most of those concerns probably only come in to play if you are dealing with retention periods longer than a few years, but I'd be inclined if I were creating a policy from scratch to cover these, even if it is from a "it is assumed that XXX will not be an issue and are beyond the scope of this process; if you expect to be holding on to this content for extended periods of time where it could become an issue, plan for it now". _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
