[HN Gopher] Petabyte tape cartridges are coming
___________________________________________________________________
Petabyte tape cartridges are coming
Author : TangerineDream
Score : 116 points
Date : 2021-02-05 14:24 UTC (8 hours ago)
(HTM) web link (blocksandfiles.com)
(TXT) w3m dump (blocksandfiles.com)
| 1MachineElf wrote:
| What would be the best way to handle a tape drive like this?
|
| Imagine investing in a 1PB tape, and then accidentally dropping
| it on the floor. Even just setting it down on a table too hard
| might brick it, or mean it needs to go back to the manufacturer
| for a expen$$$$$ive repair.
|
| Gravity seems like an unreasonably large risk for such a valuable
| object. Maybe the ideal environment for these is a zero-gravity
| one? Perhaps the future of "big data" is somewhere out in space?
| atlbeer wrote:
| Google: "tape library robot"
| eurekin wrote:
| Or forgetting to remove from pocket during an MRI scan
| Sharlin wrote:
| These are not meant to be handled by human hands.
| KaiserPro wrote:
| these tapes are going to be fairly cheap (<$400) by 2035.
|
| But more importantly, if its an LTO-style tape, it'll be fairly
| solid.
|
| even without the case, you can drop them and not worry too
| much. Lord knows I've dropped loads in my time.
| fl0wenol wrote:
| If you google this technical white paper from HP (a major LTO
| vendor) you'll see that the format (in all iterations) is
| designed to be pretty durable:
|
| 4AA4_3781EEE.pdf
|
| In particular, they test dropping tapes hundreds of times from
| 30" AFF onto concrete in different orientations, making sure
| they'll still work properly. Not every vendor does this, but
| they all like to be perceived as archival quality and durable.
|
| I wouldn't be too worried.
| madpata wrote:
| Are you called Linus Sebastian?
| RandallBrown wrote:
| Are tapes particularly fragile? At least any more fragile than
| most other media?
|
| I remember being pretty rough with audio and video cassettes,
| but then again those aren't digital so some damage probably
| wasn't noticeable.
| dragontamer wrote:
| Assuming you can read/write at 512 MB/s, it would take 24-days to
| read/write a full Petabyte.
|
| Despite the long time to read/write, any situation where capacity
| is king (aka: any Tape-drive solution today), probably benefits
| from something like this.
|
| This isn't a solution where you backup / restore from per se, but
| instead provide dozens of backups to (and probably only restore
| once from). Every day, you backup up to 42TBs of data (512MBps
| going full tilt for all 24-hours).
|
| Then, when your backups fail, or someone asks for data from 3
| weeks ago, you rewind the tape and grab that data. Crazy that
| this would all fit on one tape potentially.
| bombcar wrote:
| LTO speed has stopped doubling with LTO-4 - it's up to 400 MB/s
| uncompressed - which by the time LTO-15 is out it might be
| around 1GB/s or more.
|
| Still a long time to write.
| frongpik wrote:
| Tbh, I think that in the near future we'll figure how to flip
| one bit worth of information in a single atom, perhaps with a
| high precision magnetic field, and use crystals to store
| amounts of data we don't have prefixes for yet.
| minitoar wrote:
| Doubtful this is useful because it's just not enough mass to
| be stable.
| smaddox wrote:
| Not anywhere near room temperature, anyways. Plus it's not
| particularly helpful to store data in a single atom when it
| takes a much larger device to read the data. NAND flash
| cells are already about as small as they can be, but now
| they're being stacked on top of each other for better
| density. This is a much more promising avenue. Holographic
| storage also leverages the third dimension for huge
| increase in density compared to traditional optical drives.
| frongpik wrote:
| What do you mean? I thought atoms in crystals are well
| localized and only oscillate around their average grid
| position.
| minitoar wrote:
| I mean that noise in the environment will interfere with
| the state of your atoms too easily.
| frongpik wrote:
| The state I was thinking about is stable electron
| configuration. If an atom has two such configurations,
| and can switch between them, that's one bit worth of
| storage.
| yters wrote:
| Could that be mediated with many read heads at different
| locations?
| dragontamer wrote:
| Tapes only have one head. Otherwise, they couldn't wind or
| rewind.
|
| It'd probably be mediated with a thicker tape with a thicker
| head: the thicker the tape, the more "data per inch" passes
| through the head, which allows bandwidth to increase. That
| would change the LTO-tape dimensions however, so that
| probably isn't an option.
|
| Fortunately, by shrinking down the size of data (more data
| per square mm), the bandwidth necessarily increases. So maybe
| this technology will have a faster read/write speed than
| today's tech.
| klodolph wrote:
| I don't see a reason why you couldn't have multiple heads.
| As it stands, in order to write a complete LTO tape, you
| make multiple passes across the tape. A second write head
| would allow you to make fewer passes across the tape to
| fill it.
|
| The data on an LTO tape is written in a serpentine manner,
| or boustrophedon if you prefer, with overlapping series of
| tracks separated by the servo tracks used to position the
| head.
| JustSomeNobody wrote:
| What would happen when one head can't write out data fast
| enough (for some reason) and the tape has to slow down
| and back up. Now, instead of one head, you have multiple
| heads that have to resync and get going again.
|
| I dunno, if multiple heads were worth it, I think it
| would be common.
| klodolph wrote:
| > What would happen when one head can't write out data
| fast enough (for some reason) and the tape has to slow
| down and back up.
|
| The tape does not rewind in this scenario.
|
| It is fairly common for the system to not be able to keep
| up with the full write speed of the tape. Just as a
| reminder, LTO7 has a write speed of 300 Mb/s, and filling
| a 300 Mb/s pipe for five and a half hours is no small
| task.
|
| There are two ways the system deals with it. First, the
| drive will slow down the tape to match the data rate.
| Second, the drive can mark a section of tape as failed
| and then rewrite that data to the next part of the tape.
| Instead of rewinding and writing over a section of tape,
| you're using up more tape this way.
|
| Tapes, like hard drives and SSDs, come with a certain
| amount of extra capacity to allow for this as well as
| other write errors.
|
| > I dunno, if multiple heads were worth it, I think it
| would be common.
|
| I'm sure that it's "not worth it", yes, absolutely. But I
| don't see major technical hurdles here.
|
| One technical hurdle would be figuring out how to, say,
| fill an 800 Mb/s pipe for six hours straight. That's
| _hard._ It gets harder when you realize that a single
| tape library might have as many as 64 or 80 tape drives.
| 64 drives, multiplied by 400 Mb /s, is 26 Gb/s.
| heimatau wrote:
| We're getting closer to writing out the Akashic records.
| Interesting recursion of our present moments that it becomes
| observable.
| chefkoch wrote:
| Tape libraries often have multiple drives and it's possible to
| write parallel to them.
| adrianmonk wrote:
| > _Assuming you can read /write at 512 MB/s_
|
| I realize that's just an assumption for the sake of discussion
| (and thank you for labeling it as one), but I think it's a
| little on the low side.
|
| Wikipedia says (https://en.wikipedia.org/wiki/Linear_Tape-
| Open#Generations) that LTO-9 can write at 400 MB/s native and
| LTO-10 is going to be 1100 MB/s.
|
| Since this new Fujifilm format is denser, I would expect it to
| be even higher speed. Although speed and density don't have a
| simple linear relationship, speed generally increases with
| density.
|
| Generating enough data to keep the tape moving without a buffer
| getting empty is an important consideration, but I think this
| product is mostly aimed at people who have enough data to back
| up that they can fill a tape in a few hours. (Otherwise, why
| spend the money on cutting edge technology?) So they probably
| have lots and lots of machines to back up, and you can stream
| backups in parallel, writing to a staging area and/or
| multiplexing onto the tape.
|
| Also, there's some risk if you leave a tape in the drive and
| append to it over the course of several days. While it's still
| in the drive, it's not quite an offline backup. The drive could
| malfunction and chew up the tape, or some software could
| accidentally rewind and start overwriting.
| sly010 wrote:
| I decided to invest in an LTE drive to periodically archive my
| ZFS based NAS. This relatively old drive support 50-150 MB/s
| with a small internal buffer. My biggest problem ended up being
| that the default tar util on ZFS on spinning rust cannot even
| saturate the 50MB/s consistently, so the drive had so stop and
| rewind (called shoe-shining). It would take ages to backup
| parts of my filesystem with lot of small files (i.e. git
| repos).
|
| I ended up writing a custom software with an adaptive scheduler
| to avoid sudden speed changes.
|
| That is to say as far as I am concerned my ancient LTO6 drive
| is too fast...
| snuxoll wrote:
| It's not exactly best practice, but instead of tarballing the
| files themselves maybe you would have better performance just
| writing a snapshot via zfs send direct to tape?
| sly010 wrote:
| I admit to have thought of that, but using a zfs stream for
| archival would make eventual restore that much more
| complicated. A single bit error at the beginning of the
| stream would make the rest of the archive un-accessible,
| whereas with tar I can literally slice the tape and still
| recover data from it.
| h2odragon wrote:
| long ago there was a utility called `buffer` that solved that
| problem. i know i've seen a "buffering netcat" go by here
| recently, that should serve too.
| throw0101a wrote:
| It's been best practice for a while in the 'enterprise' realm
| to do disk-to-disk backup first so that the streams are all
| sequential and then copy to tape. Enterprise-y software can
| also generally multiplex multiple clients to a single tape.
| kstrauser wrote:
| I used Amanda Backup[0] for years on a Unix farm, and
| that's exactly how it works. Client apps on all of the
| machines being backed up ran tar and streamed the output to
| a backup server where it was written to disk. Then the
| completed files were streamed out to the tape.
|
| [0] http://www.amanda.org
| TedDoesntTalk wrote:
| I don't understand how this scales. If you have 1 PT to
| backup to tape, your first have to write it to disks on a
| backup server? So you have to buy 1PT worth of backup
| disks first, is that correct?
| kstrauser wrote:
| You wouldn't usually backup the whole thing first. That 1
| PB is probably a bunch of smaller projects, so you'd
| create a tar of the first project, then flush it to tape.
| Tar up the second project, then flush it to tape.
|
| It's not so bad if you're writing 23 tarballs out to tape
| and pausing between each one. What you really want to
| avoid is where the tape drive is pausing many times
| during a single archive, perhaps because tar can't keep
| the drive fed while it's traversing a big directory of
| teensy files.
| dragontamer wrote:
| You'd never buy a 1PB tape drive if you only had 1PB of
| data to backup.
|
| A 1 PB (1000TB) tape drive would probably cost $10,000+
| to $100,000. The tapes themselves would be cheap (cheaper
| than hard drives or SSDs). So you'd buy many tapes,
| perhaps 50 of them, to be cost-effective.
|
| That's why a lot of comments around here are talking
| about tape libraries (entire boxes of tapes). You must
| plan to use more than 50 tapes (aka: 50PBs) before you
| reach any level of cost-effectiveness.
|
| ---------
|
| From there, we see that 1PB of data is simply
| "infrastructure", to help you lay out the data before it
| gets to the tape. There are 20TB hard drives today: a
| single machine with 50 x 20TB hard drives (and maybe some
| flash storage to accelerate the write to hard drives) is
| what we're looking at to feed the Tape Drive.
| NovemberWhiskey wrote:
| Sure, why not? It's an incremental cost of the backup
| system. Look at the current generation stuff. An LTO-8
| drive puts 30TB onto a tape, but that's assuming 2.5:1
| compression, so the native capacity is only 12TB.
|
| Let's assume you're actually going to do the compression
| as you build the virtual tape. What's a 12TB hard disk
| cost these days? A lot less than the $4,000 that the tape
| drive costs. Heck, 12TB of SSD is going to be cheaper.
| throw0101a wrote:
| 60x18TB drives and a server to put them in would cost
| about US$ 45K:
|
| * https://www.45drives.com/products/storinator-
| xl60-configurat...
|
| That gets you about 1PB raw.
| kmeisthax wrote:
| I would highly recommend jacking up the --blocking-factor on
| tar (or your custom software) as high as your drive will
| accept. AFAIK the default on tar is 512b which is utterly
| inadequate, and even sequential data on a fast SSD will shoe-
| shine when written directly to tape.
|
| AFAIK most large businesses wind up writing to disk and then
| queuing the resulting serialized virtual tapes for actual
| writing at a later time. This basically turns the virtual
| tape library into a massive write buffer. It's absolutely
| insane that we have to do this - but a lot of archival
| utilities aren't built for async/parallel IO and thus aren't
| taking advantage of modern storage devices.
| swiley wrote:
| Tar not working for modern tapes by default is pretty
| ironic.
| sly010 wrote:
| The tool I ended up writing does essentially something very
| similar:
|
| - It uses a block size that matches the disk
|
| - It uses 50% of my RAM as a ring buffer
|
| - On start (and on buffer underrun) it waits for the buffer
| to fill before it starts writing to tape.
|
| - It adjust the tape write speed as an exponential function
| of the buffer fill level. I am proud of this last one. It
| is very simple and automatically converges to the best
| average speed to keep both the tape speed and the buffer
| level relatively stable.
|
| I have been considering making the reading multi threaded
| to make use of more disks, but that would be a bit of an
| overkill for my personal 2 disk NAS.
|
| edit:formatting
| js2 wrote:
| - How many TB are you backing up?
|
| - How frequently do you perform backups?
|
| - How often do you do fulls vs incremental?
|
| - What drive/autoloader are you using, and what was the
| total investment in drive + tapes?
|
| I keep considering a used LTO but I've only got 20 TB and
| it doesn't seem worth the trouble. I should just buy
| another 20 TB of drives and keep them offline when not
| backing up.
| russellbeattie wrote:
| 14 years from now? Call me a luddite, but I'm going to hold off
| even thinking about this until then. Maybe I'll get one for my
| retirement party a couple years later...
| asien wrote:
| Same reaction.
|
| That's a hell lot of time honestly, I don't what the world will
| look like in 15 years.
|
| That said 1PTB is really massive amount of data
| at_a_remove wrote:
| The generations so far has been roughly once every 2.5 years.
| Stretch it out to three years. Nor has each generation provided a
| doubling. Let's suggest a factor of 1 and two-thirds, to be on
| the safe side.
|
| We could then expect LTO-10 in 2023, LTO-11 in 2026, LTO-12 in
| 2029, LTO-13 in 2032, and LTO-14 in 2035, with a final
| uncompressed capacity of about 234 TB. Note that I have been
| conservative for both the generations and the increases in
| capacity. If you squeezed in an extra generation and assumed a
| full doubling each time, you would end up at 1,152 TB, or the 1
| PB predicted by the article.
|
| This looks to be ... right on schedule.
|
| Now if the cost of the drives would only come down ...
| samstave wrote:
| Honest question, is it the data-capacity-scale of LTO tape to
| be the driving factor instead of using a lot of micro SSD for
| example?
|
| I haven't used LTO tapes in a long while so I am not current on
| modern backup strategies... but is tape still king in backups?
| jandrese wrote:
| MicroSD cards are nowhere near reliable enough to stripe a
| petabyte of data across them. At current prices it would also
| cost around $120,000 + the cost of the readers and the robot
| to swap them around.
| at_a_remove wrote:
| Just geometrically, tape will be king for ... quite some
| time.
|
| Imagine a HDD platter. You can only write to the surface of
| it. That's a small surface area, when you think about it. Now
| imagine the surface area of an unspooled tape ...
|
| Of course, SSDs are a different beast but they are nowhere
| near as dense.
|
| The spooling and unspooling for the geometric advantage is a
| tradeoff between time and space. Therefore, tape will
| continue to reign supreme for colder backup up until such
| time as some kind of holographic, volume-penetrating
| technique reaches the sheer density of a wound tape, adjusted
| by some kind of time factor for the read-write of our
| hypothetical holocube.
| adrian_b wrote:
| Tape is the only commercially-available storage medium that
| can be used for long-term archival storage, e.g. 10 years or
| more. The tapes are typically specified for 30 years storage
| time, but it is likely that you will have to transfer the
| content on larger tapes earlier than that or you might not be
| able to find compatible drives.
|
| Nonetheless, a 10 year storage time is easily achievable with
| tapes.
|
| There are no competitive devices. The optical disks have a
| far lower capacity. Moreover, except those made with gold,
| which are no longer produced, the metallic mirror will
| oxidize after a few years and the disk will become impossible
| to read. The SSDs and other flash-based devices lose the
| charge after a few years. The HDDs that are not in active use
| will develop after a few years mechanical problems and they
| may remain stuck.
|
| There are other technologies that could be used to make
| memories suitable for archival purposes, but nobody has tried
| to develop commercial products. The market is small, because
| most people do not think much about the future so they
| discover that they should have spent more on archival storage
| only after some precious data is lost and it can no longer be
| retrieved.
|
| In my home, I am using LTO-7 tapes to store data whose loss I
| consider unacceptable. For example, because of space
| problems, I have scanned a huge quantity of books that I had
| previously, then I have destroyed or donated the paper
| copies. Since now I only have the digital copies, which are
| much more prone to irremediable loss than the paper books, I
| take serious precautions to avoid any such loss, e.g. for
| each file I store copies on 3 tapes, which I keep in
| different locations.
| at_a_remove wrote:
| Gosh I miss the old MAM-A gold DVDs. Are there none left?
| Shivetya wrote:
| Well, maybe.
|
| We use LTO6 to backup daily 60tb of data from production,
| so ten tapes a set. 14 dailies, 13 monthlies, and 7
| yearlies.
|
| We are probably moving to a Data Domain solution; as in
| spinning disk; but the key to archival security is that
| backups are replicated between two sites that are
| geographically separated. space usage is minimized by
| compression and logic that can treat newer backups as
| extensions of existing data rather than duplicating all the
| data again.
|
| the big advantage is restore speeds. spinning up ten tapes
| which we write simultaneously because of speed needs is
| cumbersome and slow with restoring a single table taking
| nearly half as long as the actual backup. On a DD system
| its less than 30 minutes and with backups replicated to
| both centers a restore can be done to production that was
| saved from the dr site; we replicate from production to dr
| and only backup dr daily.
|
| the issue with tapes has been you never know when the one
| you need is gone bad until you need it. it is also not
| common to replicate tape sets but a disk base solution
| lends itself to easy replication and transmission from site
| to site.
|
| so I can see both solutions working side by side for some
| companies but for many the disk based backup solutions that
| are out have come down in price; most are leased; as
| storage devices have dropped.
|
| are biggest limitation still is the number of ports between
| system and backup devices.
| Beached wrote:
| tape is still king of long term or cold backups. most people
| also keep hot backup on hdd or ssd in addition. but there are
| usually off prem long term cold storage backups along with
| these and those are very often tape. these tapes are for like
| FUUULLL dr and not often used but kept as insurance against
| the hot short term backups getting hosed
| tzs wrote:
| Here's what I want.
|
| A box that has a tape drive and a hard disk. For every disk write
| my computer does, I want it to send to the box a copy of the
| data, what disk it was written to, and what sector number.
|
| I want the box to store that information on its hard disk. When
| it accumulates enough that writing it to tape would not be too
| inefficient [1], it should write it out to tape and free the
| space on its hard disk.
|
| I monitored my SSD writes for a few years, to see how long it
| would be before I had to worry about hitting their write limits.
| I found that I was writing under 3 TB/year on both my home and
| work machines.
|
| A box like that, even with a modest size current tape cartridge,
| would be enough to handle all of my computers for several years
| before filling up the first cartridge.
|
| [1] I don't know if this is still the case, but it used to be
| that when tape drives stopped and started, you'd get a gap that
| wasted some tape.
| Keyframe wrote:
| So, backblaze / dropbox.. but in a physical box?
| nayuki wrote:
| Why can't we have higher density optical disc formats? Is BDXL at
| 128 GB really the end of technological innovation?
| shiftpgdn wrote:
| I would still love to find out if the statement that early AWS
| Glacier backups were done to BDXLs is true.
| aidenn0 wrote:
| Previous optical disc formats reached critical volume from
| content companies.
|
| Now that it's possible, they would much rather get the
| recurring revenue of you renting access to their content.
| ghaff wrote:
| They're happy to sell you Blu-Ray discs if that's what you
| want. Consumers, which is where most of the market is, don't
| really need higher capacity for anything. And even a 10x
| increase for BDXL probably doesn't really get you to a
| capacity that's all that useful for most types of archiving.
| aidenn0 wrote:
| You're right that my reason is probably overly cynical,
| particularly if 128GB is large enough for 2 hours of 8K
| content. The point still stands that without millions of
| drives being manufactured, the pricing would force any new
| optical medium to be expensive.
| djrogers wrote:
| > And even a 10x increase for BDXL probably doesn't really
| get you to a capacity that's all that useful for most types
| of archiving
|
| Sure it would - it would get over the 1Tb point, which
| would mean most users could back up their devices to a
| single disc again.
| ghaff wrote:
| I expect the economics wouldn't work out for most
| consumers. (And even if they did, how many would actually
| make regular backups?) And I'd point out that they can
| backup, even in an automated way, multiple terabytes to
| about a $100 disk drive today.
| kmeisthax wrote:
| It isn't; there's a next-gen archival disc format called
| Archival Disc with 300GB discs and plans to scale to 1TB/disc.
| It's only used in cartridge library systems like Sony's ODA,
| which cost about as much as tape drives do.
| des429 wrote:
| Just curious -- who's using these today? Is it mainly for cases
| where you need to be able to easily physically transfer data?
| tomerico wrote:
| An example is the large hadron colider, where each experiment
| produces an enormous amount of data from all sensors.
| atty wrote:
| That's not just the LHC - it's pretty common across high
| energy physics, nuclear physics, and astronomy, at least.
|
| It's a pretty great fit for the technology. You keep the most
| recent data on hard drives for analysis, and as new data
| comes online, the old data goes to tape. You don't want to
| get rid of the old data, of course, because you need it for
| analysis verification and when people come up with new
| analysis ideas, but the older data naturally gets accessed
| less and less as time goes on, making tape storage a natural
| choice.
| [deleted]
| [deleted]
| hobojones wrote:
| I've been told that NOAA uses tape to stream time series
| weather data into long-running simulations.
| postalrat wrote:
| All data is stored physically. All backups are physical.
| ephimetheus wrote:
| They're used by heavily by CERN to archive the LHC data. In
| ATLAS, we actually have to go back and reprocess that old data
| sometimes. So there's dedicated software that runs on the grid
| to stage petabytes worth of data back onto hard drives,
| distribute them across the grid, process and then wipe the
| disks again. There are even tape robots in the data center here
| :)
| fulafel wrote:
| It's probably more expensive to use disk for what you'd get
| from a tape robot, considering the worse reliability and shelf
| life of disks and near-absence of hard disk loading robots on
| the market.
| 1MachineElf wrote:
| A former IBMer told me a story about working at some large US
| government tape library with a tape robot that was
| essentially a powerful industrial 6-axis arm with sensors on
| top of treads. It did a good job shuffling tapes until
| someone accidentally messed up one of it's guides, after
| which said robot proceeded to crash through a brick wall.
| amelius wrote:
| At least it didn't crash through a pile of tapes containing
| valuable data.
| sly010 wrote:
| I use LTO to archive my home NAS periodically (see my comment
| above). I admit the decision to purchase the (rather expensive)
| drive was influenced by curiosity, not cost or convenience. But
| now I can keep hard copies of my entire digital life off-site
| at no additional cost for decades at a time.
| KaiserPro wrote:
| They are still used in VFX a lot.
|
| Its a good way to move entire shows to and from online storage.
| Its effectily a one off cost, vs a continuous cost for power
| and cooling. Its also a fast way to move data from one company
| to another. a ten drive robot is many times faster than 10gig
| ethernet.
|
| For other companies its attractive because tape is literally
| offline. Once its out of the robot, there is no automatic way
| to get it online again. This means that its far harder to
| tamper with.
| awiesenhofer wrote:
| Everyone who has lots of data and wants to store it as cheap as
| possible - tape is still the cheapest medium in $/TB. (Provided
| you have enough data, otherwise the initial overhead for drives
| and a robot might pivot the equation towards HDDs)
| jonatron wrote:
| Some video production companies use tape for archiving. If
| internet speed isn't fast, it can be the only realistic and
| cost effective option.
| throw0101a wrote:
| Insurance companies and banks for one.
|
| Once you've invested in the initial infrastructure (drives,
| libraries), the incremental cost of extra tapes isn't that
| much, so you can keep things on the shelf for a long time for
| not a lot of money.
|
| Send to two tapes for resiliency and every few years to a tape-
| to-tape copy to stay on the latest hardware. LTO drives can
| read two generations back: the just-released LTO-9 stuff can
| read LTO-7 tapes, and also write LTO-8.
|
| Though a lot of backup software supports S3 APIs, so some folks
| are sending (encrypted) bits to Amazon Glacier (Deep Archive)
| since they practically will never have to retrieve it.
| kstrauser wrote:
| Some types of tape have append-only mode, which is great for
| things where you want your backups to be immutable and
| auditable. Imagine a logging server that writes to tape
| regularly so that the logfiles can never be deleted or altered.
| That's super handy!
| temp0826 wrote:
| Not nearly as uncommon as you'd think. Bigcos have all sorts of
| data requirements. One of my first jobs involved pulling tapes
| from libraries and sending them off to Iron Mountain every day
| (and on occasion retrieving and restoring from said tapes).
|
| On the biggest end, you have folks like AWS glacier with an
| absurd amount of homemade libraries (and generally no tapes
| stored on/off-site outside of libraries)
| ghaff wrote:
| I thought the consensus was that Glacier uses cold storage
| disk drives. It was speculated early on that Glacier was tape
| but AFAIK that was never confirmed and there's no published
| evidence that's actually the case.
| awiesenhofer wrote:
| I always liked the rumors about it being huge BDXL
| libraries best. For example this HN entry:
| https://news.ycombinator.com/item?id=7647571
|
| IIRC Facebook actually built something similar for their
| cold storage.
| ghaff wrote:
| I find it a bit surprising that AWS has been able to keep
| this such a secret, especially given that I would have
| imagined that big enterprise users would presumably want
| to know what Glacier actually is before depending on it.
| [deleted]
| pacaro wrote:
| I've never seen compelling evidence that Glacier isn't just a
| different API and pricing policy on top of S3
| kondro wrote:
| $0.99/TB replicated with Cold Storage seems pretty
| compelling to me.
| dolni wrote:
| Big companies that have a sizable on-prem data center and need
| a cost effective way to store backups off site.
|
| At least that was the case at a place I worked ~5 years ago.
| chefkoch wrote:
| You backup to a disk array and offload the stuff you want to
| keep to tape for offline storage.
| peter_d_sherman wrote:
| Fascinating!
|
| My curiosity is, could functioning transistors somehow be created
| on either a BaFe or SrFe substrate by a magnetic or other
| electromagnetic beam of some sort?
|
| Perhaps one of those is the material for doing something like
| that...
|
| Anyway, amazing storage capacity!
| ksec wrote:
| Would there be a market for a smaller pro-sumer version Tape
| Drive Backup? May be the size of Mini Disc Or Zip Disc at around
| 5TB.
|
| What are the current strategy for consumer offline backup. Simply
| copying to another HDD?
| adrianmonk wrote:
| There used to be, but that market died. Back in the 90s, some
| formats were relatively popular with power users and small
| businesses:
|
| QIC (https://en.wikipedia.org/wiki/Quarter-inch_cartridge)
|
| Travan (https://en.wikipedia.org/wiki/Travan)
|
| Data8 (https://en.wikipedia.org/wiki/Data8)
|
| I think what killed them is economics. The per-gigabyte cost is
| lower because tape media is cheaper than hard drives, but the
| initial investment is much higher because tape drives are
| expensive. The reason tape drives are expensive probably has to
| do with manufacturing volume but I'm sure also it's because
| they are mechanically complex. You need to wind tape onto a
| spool, you need to keep it at the right tension, and there's
| the loading/unloading of the tape cartridge.
|
| And tape drives have wear and tear (tape physically dragging
| across the head), and when the drive breaks, it's expensive to
| repair, which is big drawback for an individual.
| rusk wrote:
| Being able to write your own optical media killed off tapes
| as consumer devices. Now that optical drives are on the way
| out there might be a place for tapes again ...
| andrewflnr wrote:
| When would they be better than flash storage, though?
| [deleted]
| Jkvngt wrote:
| Remember 3D holographic data cubes? I was promised, in the
| mid-1990s, that we'd have them by 2000 and that they would have
| "up to" 100 times the storage capacity of a DVD.
| gcblkjaidfj wrote:
| technically, every flash memory today is a cube (well, more of
| a skewed cube, a Parallelepiped)
|
| Mostly because they can't figure out how to make things faster,
| or as fast as the interface which keeps getting faster, so they
| just pile a bunch of flash controllers on top of each other.
| Everyone is running stripped RAID-0 and don't even know it.
|
| And if you consider that it also uses varying analog voltage
| values on each node (!SLC), it is arguably a 4d cube. Take
| that, 90s!
| busterarm wrote:
| Also microfiber-based data storage media (first paper on this
| was in 1998) which require new lasers that we still don't have
| yet.
| Jkvngt wrote:
| I guess I'm just going to have to see it in a store to
| believe it.
| _ph_ wrote:
| I worked on holographic data storage in LiNbO3 crystals in the
| early 2000 years. We had a lab prototype which would store over
| 1 GB in roughly a sugar cube size of crystal. The technology is
| certainly possible. However, the amount of optics required made
| it a huge and expensive system and there was not a lot of
| funding. Using modern diode lasers, the setup could be
| minimized a lot. However, the big limit is the wavelength of
| light. Green light has roughly 500nm of wavelength, and that
| determines the smalles features. This value back then was small
| but is huge compared to modern chip structures. We were losing
| the density battle even back then. There is one trait still not
| matched though: stability. Those crystals are about the
| toughest things imaginable. Unless you smash them with a
| hammer, they won't rot or decay. Storage times of hundreds if
| not thousands of years would be possible.
| mnw21cam wrote:
| Yeah, so we currently have micro-SD cards with a 1TB capacity,
| which is 100 times the storage capacity of a DVD. I see your
| holographic data cube and raise you a fingernail.
| swiley wrote:
| I guess it's still glass with incredibly tiny details etched
| into it, just not quite as fantastic looking.
| Jkvngt wrote:
| So you're saying this tape claim will end up being some new
| form of CD?
| google234123 wrote:
| That's not at all what he is saying.
| EvanAnderson wrote:
| Every few years I remember the story from 2000-2001 claiming
| that a German research lab successfully stored 10GB WORM on a
| roll of clear sticky tape ("Scotch" tape).
|
| I couldn't really tell if it was serious or not at the time,
| but it looks like nothing has come of it.
|
| [1] https://uat.designnews.com/automation-motion-control/tale-
| ta...
|
| [2] https://tech.slashdot.org/story/00/03/18/1218250/scotch-
| tape...
| jeffreygoesto wrote:
| Oh the good times... I remember when before christmas Steffen
| and Matthias goofed around in the university basement with
| their equipment... Actually they pivoted from data storage to
| security and anti tamper stickers, and are still in business
| [0, 1].
|
| Steffen Noethe is into life sciences since 2013 [2].
|
| P.S.: It did work for up to five or so layers, then focusing
| and laser power were hard to handle. They never developed a
| robust drive from that principle and the spot in between
| flash, DVDs and tape was closing too fast to create enough
| business...
|
| [0] https://www.tesa-scribos.com/de [1]
| https://www.tesa.com/en/about-tesa/press-
| insights/stories/th... [2]
| https://www.linkedin.com/in/steffen-noehte-b318a728
| EvanAnderson wrote:
| Thanks for that! I love the power of HN to reach people
| with personal knowledge about technology.
|
| For anybody else interested, I believe we're talking about
| this patent: https://patents.google.com/patent/US6386458B1
| jeffreygoesto wrote:
| Just contributing my iota where I can... =:-)
|
| You are right, that is one of them. There's some more
| even...
|
| [0] https://patents.justia.com/inventor/matthias-gerspach
| awiesenhofer wrote:
| I kinda miss this "storage media enthusiasm" of the late 1990s
| and early 2000s. Sure I like my usbkeys and cloud storage, but
| its just not the same as "data cubes", scotch tape or even just
| actual products in these weird "in-between" times back then
| like jaz&clik drives, minidiscs, etc. (microSD cards are pretty
| cool though)
| gorgoiler wrote:
| I cut my teeth on tape -- Travans, IBM3590, IBM3592...
|
| Cold storage is a wonderful thing. A mechanical bridge from the
| ethereal to the real world with a true disconnect between the
| medium and the mechanism. I worry about the longevity of our data
| but some people are doing good things.
|
| _Act now! Support your local internet archive!_
___________________________________________________________________
(page generated 2021-02-05 23:01 UTC)