<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Cloning to a spare drive is very good
advice. In addition, we schedule a swap or re-clone annually for
each instrument. Disk drives can go bad just sitting on the shelf,
so it's important to test them. We are slowly transitioning to
solid-state drives, which presumably have a longer shelf life.<br>
<br>
We have had to turn to eBay to find old motherboards and strange
old power supplies. You can't count on the vendors to keep spare
parts.<br>
<br>
<div class="moz-signature"> <br>
<font size="-2">--------------------------------<br>
Michael Rooks <br>
Yale Institute of Nanoscience and Quantum Engineering <br>
<a href="http://nano.yale.edu">nano.yale.edu</a>
</font>
<br>
<br>
<br>
<br>
</div>
On 11/12/2014 08:27 PM, Bill Flounders wrote:<br>
</div>
<blockquote cite="mid:5464091F.1030100@eecs.berkeley.edu"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Nathan,<br>
We use three options:<br>
1. make mirror image, store on server<br>
2. clone drive to new properly formatted drive, store in cabinet<br>
3. clone drive to new properly formatted drive, store in PC<br>
as Drive "d" ( or other) and leave disconnected but ready to go<br>
<br>
We track as a "dependency" of the tool.<br>
It is time consuming and requires discipline.<br>
It has saved us on numerous occasions.<br>
This does not address the difficulties of embedded PLC programs.<br>
<br>
The real discipline and difficulty lies in upgrades.<br>
A new SW version is installed, or a new driver to go with the
new board etc<br>
and the clone is not remade. Then the day comes you need the
clone and<br>
install it and several communication errors arise that you've
never seen before.<br>
<br>
As for non disk hardware failures, that is why many of us have a
closet<br>
with a few 386's with ISA slots and other arcane hardware.<br>
This is also why we post old computers/tools to the network in
that rare <br>
instance that we ever retire a tool - so that other members with
the same tool<br>
can put our old computer or some specialty boards in their
emergency closet.<br>
When all else fails, ebay - usually at least two purchases
required.<br>
<br>
Finally, there is the dream that we will upload all of our
systems to The Cloud<br>
and whenever any of us needs a unique, antique OS or custom
program -<br>
It will Be There... without any issues such as version
control, license fees,<br>
export control etc., etc.<br>
Good Luck,<br>
<br>
Bill Flounders<br>
Berkeley NanoLab<br>
<br>
<br>
<br>
Nathan Nelson - Fitzpatrick wrote:<br>
</div>
<blockquote
cite="mid:D088E20D.1C963%25nathan.nelson-fitzpatrick@uwaterloo.ca"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>Hi Labnetwork,</div>
<div><br>
</div>
<div>Over the past year our lab has seen quite a few new tool
installations and as a result we now have over thirty tools
(microscopes, EBL, deposition/etch systems, etc…) that have
some sort of interface with a personal computer. Many of
these personal computers are run-of-the-mill consumer grade
PCs and I think that running this many computers over a
many-year timescale will mean that failures are virtually
guaranteed. I’m very interested in knowing how larger labs
with many computers (with many different port configurations,
hardware requirements, and operating systems) prepare for and
deal with this problem. </div>
<div><br>
</div>
<div>At our site, we are simply cloning the various tool hard
drives (using Clonezilla) onto external hard drives that sit
on a shelf in my office. This is time consuming and requires
some discipline to keep going. The other problem with this
approach is that it does not really protect us in the case of
non-disk hardware failures (such as a motherboard failure).
I’d love to know the philosophies and approaches that larger
labs employ to deal with this problem.</div>
<div><br>
</div>
<div>Thanks,</div>
<div> -Nathan</div>
<div>
<div>-- </div>
<div>Nathan Nelson-Fitzpatrick PhD</div>
<div>Nanofabrication Process Engineer</div>
<div>Quantum NanoFab</div>
<div>University of Waterloo</div>
<div>200 University Avenue West</div>
<div>Waterloo, ON Canada N2L 3G1</div>
<div>Ph: +1 519-888-4567 ext. 31796</div>
<div><br>
</div>
<div><span class="Apple-style-span" style="border-collapse:
collapse; color: rgb(80, 0, 80);">
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt;
font-size: 11pt;"><br>
</p>
<span class="Apple-style-span" style="font-size: 15px;"><br>
</span>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt;
font-size: 11pt;"><br>
</p>
</span></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
labnetwork mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:labnetwork@mtl.mit.edu">labnetwork@mtl.mit.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork">https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
labnetwork mailing list
<a class="moz-txt-link-abbreviated" href="mailto:labnetwork@mtl.mit.edu">labnetwork@mtl.mit.edu</a>
<a class="moz-txt-link-freetext" href="https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork">https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork</a>
</pre>
</blockquote>
<br>
</body>
</html>