Offline media storage

Light proof metal boxes:

A good drawer will store many of my 4 TB Toshiba USB drives.

For high level EM pulses use metal drawers?

The advantage of drawers is that things cannot easily fall like from shelves.

Anyways even 20 year old CDs I burned still playback, the secret: darkness exposure time multiplied by light intensity like in photography.

The big challenge is to make sure you have playback means I bought an USB floppy drive for the old floppies. USB DVD and Blueray players ? I think those exist too And then USB will become old...

Maybe carve in stone in old underground caves. If aliens land here they will conclude life once existed here...

I mean when trump is allowed to go on making war, goes nuclear.

I've been copying optical media onto magnetic disks as a matter of convenience (I can mount any of 1000+ optical disks just by spinning up one magnetic disk) and as a safeguard against "recordables" getting bitrot.

I don't have much faith in thumb drives. Especially higher densities/capacities. Even old SLC have "developed problems" so I don't rely on them (though I have been buying "lots" of "recovery media" (8GB) to use in place of optical media as relying on those drive mechanisms is also becoming tenuous.

I figure a 3.5" disk fitted into a 1"x3.5" slot will only fall out if the shelf unit falls over. There, the design issue will be ensuring the "shelf" is not tall and slender but more "squat" to keep the center of mass low.

But, storing lots of drives "cold" almost feels sinful.

I have kept my writeable media in black tyvex-like sleeves in boxes salvaged from the USPS (one of their "fixed price" boxes is exactly as wide as sleeved optical media). You need an ordered list, though, to locate a specific medium (and have to take care to replace it in the spot from which it came!)

I still have an *8* inch, NIB (floppy) drive (with electromechanical lock on the door! I used this with a large disk cache on a Z80 machine to prevent the media from being removed until the cache was explicitly flushed to the medium). But, I think the magnetic media of interest has long since been transcribed so the drive is redundant.

My EPROM programmer requires 3.5" floppies to operate so I keep a laptop with 3.5" drive on hand for that.

Without a doubt, *the* long-term interface is a NIC. It's as close to ubiquitous as you can get, has a long history with no foreseeable end in sight (in terms of hardware and protocols)

I think SATA/SAS drives will have available kit for a while (even if salvaged; it's an electronic interface so nothing mechanical on which to rely). And, damn near any box with at least one SATA/SAS interface will almost certainly have a NIC so getting to the data from another box doesn't rely on having a "special" interface on that box!

I'm more worried about the rapidly increasing capacities; I won't use anything bigger than ~8T as it just takes too long to transfer all of the content to another box (8T/200MB/s=11hrs). I've been piling up 14T drives as I can't think of anything to put *on* them (that I would be willing to wait to recover!)

Yes, some oif fthse thub drives failed on me But those Tisiba 4TB are good old spinng magnetics

Yes I have q text file 'dvd list,

This is an example of an entry (box was almost full hosts 100 discs)

-rw-r--r-- 1 root root 19095 May 7 23:33 xinutop_manual.txt

-rw-r--r-- 1 root root 4385000000 Jul 1 18:01 freibeuter_des_todes_german.ts amovie

-rw-r--r-- 1 root root 58 Jul 11 10:40 xinutop-nav-x86-2.4.img.md5

-rw-r--r-- 1 root root 682624000 Jul 11 10:44 xinutop-nav-x86-2.4.img

-rw-r--r-- 1 root root 4294705152 Sep 8 01:51 stones_havana_NPO_3-20190907213907-.mts amovie

-rw-r--r-- 1 root root 627385344 Sep 8 02:28 stones_havana_NPO_3-20190907213907-.mts1 amovie

-rw-r--r-- 1 root root 3949971456 Sep 8 05:59 stones_havana_NPO_3-20190907235958-.mts amovie

-rw-r--r-- 1 root root 1993500000 Sep 24 16:53 the_great_wall_2016.ts amovie

-rw-r--r-- 1 root root 2354400000 Oct 3 17:05 last_man_standing_1996.ts amovie

-rw-r--r-- 1 root root 3172370000 Oct 8 12:39 a_cure_for_wellness_2016__german.ts amovie When you make DVS or other backups, make sure you do not include personal stuff in it That is whey I make a file system as above and clear the entry like this dd if=/dev/zero bs=100000000 count=242 > bluray.iso mke2fs bluray.iso mount -o loop=/dev/loop0 bluray.iso /mnt/loop

Unfortunately my 8 inch drive that I used for my Z80 sysytem is no more. Some stuff I did backup though

Ah! only need a serial port ;-)

I leave most of my spindles "off", only powering up the device that contains them when I need to access something stored on them.

My workstations each have 4 drives but even those don't run 24/7 -- spinning down when I walk away from the machine.

I rescue SAS (and some SATA) "enterprise" drives -- 33 4TB drives last month, each with four or five power-on-hours (i.e., essentially "new")

I don't backup to optical media -- too small for anything but an incremental backup (and I *hate* those!)

My DVDs are usually archives of completed projects -- all the datasheets, tools, sources, schematics, invoices, receipts, etc. I don't keep much "paper" so need some way of remembering what was involved.

I've taken to just keeping entire VMs so I can resume work with a particular project *in* the environment that was in place when I last worked on it. I can quickly duplicate a VMDK and then play around without worrying about corrupting the archive of the project.

When I discard media, I have a tool that I built (for a nonprofit) that scrubs the disk clean -- including HBA, DSO, etc. If it "discovers" that some number of sectors have been remapped (I never use a disk with remapped sectors so anything remapped MIGHT contain remnants of prior content), then the disk gets physically destroyed (drilled or shredded).

I had trouble backing up the 8" media from the ZDS's (hard sectored floppies). But, resorted to transfer via XMODEM.

But, in recent years, rely on network boot protocols for most of the devices I design (putting just a tiny bit in a boot rom to bring the network on-line).

A few hundred terabyte? Yikes! It might be time to not just get rid of kit but also of tons of data.

My whole business backup is less that 20GB and that's decades of engineering, book keeping, tax stuff et cetera.

I've digitized all of my textbooks and novels (in high resolution to improve OCR) as well as imaged every audio/video/data CD/DVD medium so I can rid myself of those "less dense" storage media (I can watch a video, read a book, listen to music sourced from magnetic media just as easily as "the original" and it takes a small fraction of a percent of the space).

The digital "libraries" are big -- I may have 300 DVDs of video effects. Or, 3D CAD models. Typefaces. etc. Having them combined on fewer media eliminates the hassle of digging through *spindles* of optical media searching for a specific item, installing it in a drive, mounting it and *previewing* its contents: "Nope, that's not the one I want!"

My rainbow table library is 16T.

But, the big pigs are the VMs. A few TB for each project to allow me to recreate the exact working environment in effect when working on that project. While I no longer support those clients, the individual projects are how I remember which tools were used for it -- and how to find them.

Of course, each build environment gets larger than the one before (as I acquired more tools and enhanced the cabilities of the machines) so each VM gets larger (the VM for my current workstation would be close to 30T spread over 4 physical machines -- that because I have copied those various libraries/collections onto their respective machines so they are more directly accessible).

And, you don't want to *run* those VMs as that alters them. So, you make a copy of a VM before tinkering with it (the tools it contains).

And, EVERYTHING in the archive needs to be replicated...

With media effectively free, the issue is only one of keeping track of "what's where" -- and physically storing *cold* drives for the time they may be needed.

I have an index on an RDBMS that tells me which files are located on each medium, meta data for each (size, hash, last used, last

Whenever a physical medium is brought on-line, a daemon queries the database to find the "most important" files that have NOT been verified in the "longest time" and immediately checks their signatures against those stored in the RDBMS -- to alert me of any corruption (a file that is never *accessed* tells you nothing about whether it

In the event a signature fails to match, the RDBMS tells me where I can find a duplicate copy of the intact file (ideally, somewhere on the same medium or one that it KNOWS is available, now) -- even if that copy resides in a ZIP/ARJ/RAR/VMDK/TGZ/etc. "container". So, I can recreate a corrupt copy in its intended spot in the hierarchies of filesystems.

This really is no different than the data management tasks a real employer would face. If called upon to revise last year's model of a product, you'd need to be able to access all of the files pertinent to it's design AT THAT TIME along with the set of tools that you had in place to manipulate those files. (e.g., you may have moved on to a different CMS, VCS, layout tool, word processor, etc. but you *still* need to be able to access, and likely MODIFY, the things you created with the prior tools!)

You may use a RAID array/ZFS pool to automate the checking and replacement of corrupt files (and likely can't peek into ZIPs to do so!) but you are still paying for the redundancy with extra media and MIPS.

Or, you are simply shedding old work.