I just wrote a storage/backup policy for $day_job, and had to deal
with some of this, so a few things to add to the otherwise good
points.

1) if these archives are kept "offline", make sure you have multiple
copies.  Drives fail.  Tapes fail.  Keep more than 1 copy.
2) Encryption on media (and make sure you save the old keys!!), or
otherwise make sure that the archives are secure.
3) Have a plan for rotation of your archive media.  Yes, this means
cycling tapes/drives/technologies periodically, even if you don't
otherwise need to access the data.  This also nicely gets around the
problem of keeping ancient hardware on hand to read old media.


On Thu, Sep 6, 2012 at 2:12 PM, 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.
>
> At the simplest, you need to find a product that allows you retention
> locking capabilities.  This can be done in a database, in software, or at
> the storage layer.  Many NAS systems provide some way of specifying
> retention locking to various degrees.  In some cases it's simplistic and can
> be overridden, and in a few cases they do it for legal or regulatory
> compliance and once you lock down a volume/disk/directory, even the
> superuser cannot remove it short of swapping out the physical hardware.
> NetApp has several kinds of compliance that you can enable (for a fee,
> naturally) like this.
>
> There are object-based storage systems like EMC's Centera, which they call
> "CAS" for "content-addressable storage".  It uses an API that many software
> packages can use to place data into various levels of retention.
>
> You could even conceivably roll your own SQL-flavored database that prevents
> anyone but the administrator from going in and deleting stuff, again
> depending on whether you require simple retention to protect against
> accidental deletion or compliance locking for legal or regulatory reasons.
>
> 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.
>
> -Adam
>
> _______________________________________________
> 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/
>



-- 
Jesse Becker
_______________________________________________
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/

Reply via email to