Adam Levin <[email protected]> wrote: > On Thu, Sep 6, 2012 at 1:31 PM, Howard Bampton <[email protected]> > wrote: > > On Thu, Sep 6, 2012 at 12:20 PM, David Parter <[email protected]> wrote: > > > > > 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- > > > > Howard brings up some excellent points -- you need to consider a lot of things > in addition to the data. As for products, though, there are a lot of ways to > handle this.
Possibly. It depends (of course) on what the actual requirements are. The specific scenarios I was thinking of is a research project has a need to archive the project data -- where data is defined by the project. It could include code, it could include test cases, reports, etc. Whatever it is, right now it is in the file system. In the case I am thinking of, it doesn't need to include access control and other meta data -- just "the data". If the archive does need to include things like version of the hardware and application software, the burden (for me) is on the research project to know that they need to include that data in their archive. [description of mechansims built into the storage device/file system deleted for brevity] I don't think the mechanisms built into some storage systems are what I am looking for -- because that still mixes current data with the archives, and relies on being able to reproduce a given version or set of data from the live file system. Maybe I'm wrong, but I think this needs to be thought of as distinctly separate objects, which are managed and stored seperately. Once there are specific archives, the data retention and destruction policy can be correctly applied to them. This is separate from normal day-to-day file system/storage operations. > As an aside, I would pedantically point out that traditional backups are not a > disaster recovery tool -- they are an operational recovery tool. DR has a lot > more involved, including replication, offsite services, infrastructure > replacement/rebuilding, etc. Sure. it depends on how you define "DR" and the scope of the disaster that you are planning to recover from (site burned down? a single disk failed? oooops I didn't mean to erase that disk?). Backups are not a complete DR solution, but the purpose of backups is to allow for data recovery after a disaster. It is not an archive. Archival has other requirements -- like long term reliability, and a way to name or otherwise identify what the archive is. Other than that, I don't know what the requirements are... but I was hoping to get some ideas from the discussion (whcih I am). --david _______________________________________________ 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/
