[labnetwork] Tool PC backups / PC redundancy

Michael Rooks michael.rooks at yale.edu
Thu Nov 13 09:13:04 EST 2014


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.

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.


--------------------------------
Michael Rooks
Yale Institute of Nanoscience and Quantum Engineering
nano.yale.edu <http://nano.yale.edu>



On 11/12/2014 08:27 PM, Bill Flounders wrote:
> Nathan,
> We use three options:
> 1. make mirror image, store on server
> 2. clone drive to new properly formatted drive, store in cabinet
> 3. clone drive to new properly formatted drive, store in PC
> as Drive "d" ( or other) and leave disconnected but ready to go
>
> We track as a "dependency" of the tool.
> It is time consuming and requires discipline.
> It has saved us on numerous occasions.
> This does not address the difficulties of embedded PLC programs.
>
> The real discipline and difficulty lies in upgrades.
> A new SW version is installed, or a new driver to go with the new 
> board etc
> and the clone is not remade. Then the day comes you need the clone and
> install it and several communication errors arise that you've never 
> seen before.
>
> As for non disk hardware failures, that is why many of us have a closet
> with a few 386's with ISA slots and other arcane hardware.
> This is also why we post old computers/tools to the network in that rare
> instance that we ever retire a tool - so that other members with the 
> same tool
> can put our old computer or some specialty boards in their emergency 
> closet.
> When all else fails, ebay - usually at least two purchases required.
>
> Finally, there is the dream that we will upload all of our systems to 
> The Cloud
> and whenever any of us needs a unique, antique OS or custom program -
> It will Be There...   without any issues such as version control, 
> license fees,
> export control etc., etc.
> Good Luck,
>
> Bill Flounders
> Berkeley NanoLab
>
>
>
> Nathan Nelson - Fitzpatrick wrote:
>> Hi Labnetwork,
>>
>> 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.
>>
>> 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.
>>
>> Thanks,
>>   -Nathan
>> -- 
>> Nathan Nelson-Fitzpatrick  PhD
>> Nanofabrication Process Engineer
>> Quantum NanoFab
>> University of Waterloo
>> 200 University Avenue West
>> Waterloo, ON   Canada  N2L 3G1
>> Ph: +1 519-888-4567 ext. 31796
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> labnetwork mailing list
>> labnetwork at mtl.mit.edu
>> https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork
>
>
>
> _______________________________________________
> labnetwork mailing list
> labnetwork at mtl.mit.edu
> https://www-mtl.mit.edu/mailman/listinfo.cgi/labnetwork

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mtl.mit.edu/pipermail/labnetwork/attachments/20141113/02310cb4/attachment.html>


More information about the labnetwork mailing list