[Pasig-discuss] Write-blocking a RAID

Tue Nov 6 06:51:23 EST 2012

Earlier this year I followed a similar but more basic version of the
process Neil described to migrate a Windows 2000 server to virtualised and
emulated hardware so it could be preserved indefinitely. The server was
running a MS-SQL database with a custom html front-end. Post migration to
emulated hardware the front-end still functioned as it originally did and
the data was still accessible.
I posted some documentation of the process here:
http://www.openplanetsfoundation.org/blogs/2012-04-23-migrating-windows-2000-database-server-virtualized-and-emulated-hardware
for
anyone that is interested.

Euan

On 6 November 2012 20:49, Neil Jefferies
<Neil.Jefferies at bodleian.ox.ac.uk>wrote:

> The elephant in the room – and the whole reason that you sometimes need to
> preserve servers rather than bits (at least in the first instance) is that
> it is highly likely to be a database driven application. Thus there is a
> likely to lot of implicit knowledge in the application code without which
> the data files on disk are largely meaningless. Short of some miracle there
> will be pretty minimal documentation for this code so the only way to
> comprehend it is to actually have it running. Then you can backtrack
> through the code, extract the implicit knowledge and start to do something
> about extracting an repurposing the data in a more tractable and
> preservable way. File formats are the least of your problems here. My
> experience is that the amount of material that arrives like this is
> non-trivial and likely to grow.****
>
> ** **
>
> The original notion of write-blocking RAID’s is a non-starter anyway. Any
> reasonable RAID system will write to the array members on startup even if
> it just basic synchronisation information. Write blocking them will cause
> the controller hardware/software to consider the devices failed, with
> unpredictable results. The standards for forensic non-repudiation are much
> higher than is realistic or cost-effective for archival purposes (despite
> what archivists think!). What you can do is image the RAID disks
> individually (and then reassemble the RAID array for the next bit) so you
> can restore the RAID array to its original condition by rewriting the disks.
> ****
>
> ** **
>
> What you actually want is to image the filesystem as presented by the RAID
> system to the OS. Traditional disk imaging tools like dd are fine for this
> with the server running normally. This image can then be mounted in a
> virtual machine and either booted/migrated as-is or, probably better,
> mounted read-only on a fresh installation of the OS in a VM and then have
> the code copied across to produce an operational VM. This can then be
> snapshotted to give you a known starting point for subsequent operations.
> If anything goes wrong you can restore the RAID members and start again (at
> least until one of the disks fails).****
>
> ** **
>
> This could be a case where preserving the bits, and worrying about file
> formats, will only get you so far. It’s about understanding and capturing
> the context in which files were created and used. A bit like books and
> letters, really.****
>
> ** **
>
> Neil        ****
>
> ** **
>
> *From:* pasig-discuss-bounces at asis.org [mailto:
> pasig-discuss-bounces at asis.org] *On Behalf Of *Michael Seadle
> *Sent:* 05 November 2012 19:19
>
> *To:* pasig-discuss at mail.asis.org
> *Subject:* Re: [Pasig-discuss] Write-blocking a RAID****
>
> ** **
>
> I agree with David and Thomas. Integrity (keeping the bits safe) is the
> first priority, and I think knowing what the bits genuinely represent
> (authenticity) also comes high.
>
> Format changes are a very manageable if the bits are there.
>
> Best wishes ... Michael
>
> On 11/5/2012 7:32 PM, Youkel, Thomas wrote: ****
>
> I truly have to agree with David on this one. Keeping the bits safe is the priority****
>
> ** **
>
> ** **
>
> Thomas Youkel****
>
> Chief, Enterprise Systems Engineering****
>
> The Library of Congress****
>
> 202-707-8355 - desk****
>
> 202-615-7794 - mobile****
>
> ** **
>
> ** **
>
> ** **
>
> -----Original Message-----****
>
> From: pasig-discuss-bounces at asis.org [mailto:pasig-discuss-bounces at asis.org <pasig-discuss-bounces at asis.org>] On Behalf Of David Rosenthal****
>
> Sent: Monday, November 05, 2012 1:16 PM****
>
> To: pasig-discuss at mail.asis.org****
>
> Subject: Re: [Pasig-discuss] Write-blocking a RAID****
>
> ** **
>
> On 11/05/2012 10:05 AM, Mark Fitzsimmons wrote:****
>
> Hi Cory,****
>
> ** **
>
> Great point. You are absolutely right, file formats will become obsolescent.****
>
> ** **
>
> This will happen over time to particular formats that you have copies of. ****
>
> ** **
>
> You will inevitably need to convert/preserve the content of those ****
>
> files to an accessible media type.****
>
> ** **
>
> An inventory of the files you have and by type will provide the ****
>
> reference point you need to track the impending migration of them ****
>
> ahead of obsolescence.****
>
> ** **
>
> Whether or not at some point in the future there is a risk of format obsolescence, the files need to be extracted and put some place reasonably safe, as soon as possible. At this stage, worrying about formats is a waste of time and effort. Worry about formats after you have all the bits safe.****
>
> ** **
>
> It is truly amazing how each and every discussion of digital preservation gets hijacked by the "OMG format obsolescence" meme.****
>
> ** **
>
> See http://blog.dshr.org/2012/10/formats-through-time.html****
>
> ** **
>
>         David.****
>
> ** **
>
> ----****
>
> To subscribe, unsubscribe, or modify your subscription, please visit http://mail.asis.org/mailman/listinfo/pasig-discuss****
>
> _______****
>
> Save the Date - PASIG Dublin, October 17-19, 2012 _______________________________________________****
>
> Pasig-discuss mailing list****
>
> Pasig-discuss at mail.asis.org****
>
> http://mail.asis.org/mailman/listinfo/pasig-discuss****
>
> ** **
>
> ----****
>
> To subscribe, unsubscribe, or modify your subscription, please visit ****
>
> http://mail.asis.org/mailman/listinfo/pasig-discuss****
>
> _______****
>
> Save the Date - PASIG Dublin, October 17-19, 2012****
>
> _______________________________________________****
>
> Pasig-discuss mailing list****
>
> Pasig-discuss at mail.asis.org****
>
> http://mail.asis.org/mailman/listinfo/pasig-discuss****
>
> ** **
>
> --
> Dean, Faculty of Humanities / Dekan, Philosophische Fakultät I
> Professor & Director, Berlin School of Library and Information Science
> (Institut für Bibliotheks- und Informationswissenschaft)
> Humboldt-Universität zu Berlin
> Editor, Library Hi Tech
> Blog: Digital+Research=Blog <http://digitalplusresearch.blogspot.com/>****
>
> ----
> To subscribe, unsubscribe, or modify your subscription, please visit
> http://mail.asis.org/mailman/listinfo/pasig-discuss
> _______
> Save the Date - PASIG Dublin, October 17-19, 2012
> _______________________________________________
> Pasig-discuss mailing list
> Pasig-discuss at mail.asis.org
> http://mail.asis.org/mailman/listinfo/pasig-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.asis.org/pipermail/pasig-discuss/attachments/20121106/13589660/attachment.html 