The long road to recover Frogger 2 source from tape drives

Wow, this part makes my blood boil, emphasis mine:<p>&gt; This issue doesn&#x27;t affect tapes written with the ADR-50 drive, but all the tapes I have tested written with the OnStream SC-50 do NOT restore from tape <i>unless the PC which wrote the tape is the PC which restores the tape.</i> This is because the PC which writes the tape stores a catalog of tape information such as tape file listing locally, which the ARCserve is supposed to be able to restore without the catalog because it&#x27;s something which only the PC which wrote the backup has, <i>defeating the purpose of a backup.</i><p>Holy crap. A tape backup solution that doesn&#x27;t allow the tape to be read by any other PC? That&#x27;s madness.<p>Companies do shitty things and programmers write bad code, but this one really takes the prize. I can only imagine someone inexperienced wrote the code, nobody ever did code review, and then the company only ever tested reading tapes from the same computer that wrote them, because it never occured to them to do otherwise?<p>But <i>yikes</i>.

In The Singularity Is Near (2005) Ray Kurzweil discussed an idea for the “Document Image and Storage Invention”, or DAISI for short, but concluded it wouldn&#x27;t work out. I interviewed him a few years later about this and here&#x27;s what he said:<p><i>The big challenge, which I think is actually important almost philosophical challenge — it might sound like a dull issue, like how do you format a database, so you can retrieve information, that sounds pretty technical. The real key issue is that software formats are constantly changing.<p>People say, “well, gee, if we could backup our brains,” and I talk about how that will be feasible some decades from now. Then the digital version of you could be immortal, but software doesn’t live forever, in fact it doesn’t live very long at all if you don’t care about it if you don’t continually update it to new formats.<p>Try going back 20 years to some old formats, some old programming language. Try resuscitating some information on some PDP1 magnetic tapes. I mean even if you could get the hardware to work, the software formats are completely alien and [using] a different operating system and nobody is there to support these formats anymore. And that continues. There is this continual change in how that information is formatted.<p>I think this is actually fundamentally a philosophical issue. I don’t think there’s any technical solution to it. Information actually will die if you don’t continually update it. Which means, it will die if you don’t care about it. ...<p>We do use standard formats, and the standard formats are continually changed, and the formats are not always backwards compatible. It’s a nice goal, but it actually doesn’t work.<p>I have in fact electronic information that in fact goes back through many different computer systems. Some of it now I cannot access. In theory I could, or with enough effort, find people to decipher it, but it’s not readily accessible. The more backwards you go, the more of a challenge it becomes.<p>And despite the goal of maintaining standards, or maintaining forward compatibility, or backwards compatibility, it doesn’t really work out that way. Maybe we will improve that. Hard documents are actually the easiest to access. Fairly crude technologies like microfilm or microfiche which basically has documents are very easy to access.<p>So ironically, the most primitive formats are the ones that are easiest.</i>

Modern backup would simply state “API keys and settings are here:”, and a link to collaboration platform closed after 3 years of existence.

Absolutely amazing story. Fantastic!<p>I&#x27;ve actually long been stunned by the propensity of proprietary backup software to use undocumented, proprietary formats. I&#x27;ve always found this quite stunning, in fact. It seems to me like the first thing one should make sure to solve when designing a backup format is to ensure it can be read in the future even if all copies of the backup software are lost.<p>I may be wrong but I think some open source tape backup software (Amanda, I think?) does the right thing and actually starts its backup format with emergency restoration instructions in ASCII. I really like this kind of &quot;Dear future civilization, if you are reading this...&quot; approach.<p>Frankly nobody should agree to use a backup system which generates output in a proprietary and undocumented format, but also I want a pony...<p>It&#x27;s interesting to note that the suitability of file formats for archiving is also a specialised field of consideration. I recall some article by someone investigating this very issue who argued formats like .xz or similar weren&#x27;t very suited to archiving. Relevant concerns include, how screwed you are if the archive is partly corrupted, for example. The more sophisticated your compression algorithm (and thus the more state it records from longer before a given block), the more a single bit flip can result in massive amounts of run-on data corruption, so better compression essentially makes things worse if you assume some amount of data might be damaged. You also have the option of adding parity data to allow for some recovery from damage, of course. Though as this article shows, it seems like all of this is nothing compared to the challenge of ensuring you&#x27;ll even be able to read the media at all in the future.<p>At some point the design lifespan of the proprietary ASICs in these tape drives will presumably just expire(?). I don&#x27;t know what will happen then. Maybe people will start using advanced FPGAs to reverse engineer the tape format and read the signals off, but the amount of effort to do that would be astronomical, far more even than the amazing effort the author here went to.

I&#x27;ve always admired the tenacity of people who reverse engineer stuff. To be able to spend multiple months figuring out barely documented technologies with no promise of success takes a lot a willpower and discipline. It&#x27;s something I wish I could improve more in myself.

Fascinating read that unlocked some childhood memories.<p>I&#x27;m secondhand pissed at the recovery company, I have a couple of ancient SD cards laying around and this just reinforces my fear that if I send them away for recovery they&#x27;ll be destroyed (the cards aren&#x27;t recognized&#x2F;readable by the readers built into MacBooks, at least)

This is giving me some anxiety about my tape backups.<p>I have backed up my blu-ray collection to a dozen or so LTO-6 tapes, and it&#x27;s worked great, but I have no idea how long the drives are going to last for, and how easy it will be to repair them either.<p>Granted, the LTO format is probably one of the more popular formats, but articles like this still keep me up at night.

I really wish they would name the data recovery company so that I can never darken their door with my business.

&gt;&gt; The tape was the only backup for those things, and it completes Frogger 2&#x27;s development archives, which will be released publicly.<p>In cases like this can imagine some company yelling &quot;copyright infringement&quot; even though they don&#x27;t possess a copy themselves. It&#x27;s a really odd situation.

As a kid, I got this game as a gift and really, really wanted to play it. But after beating the second level, the game would always crash on my computer with an Illegal Operation exception. I remember sending a crash report to the developer, and even updating the computer, but I never got it working.

I work in the tape restoration space. My biggest piece of advice is never NEVER encrypt your tapes. If you think restoring data from an unknown format tape is hard, trying to do it when the drive will not let you read the blocks off the tape without a long lost decryption key is impossible.

TIL there are <i>three</i> completely different games named &quot;Frogger 2&quot; I assumed this was for the 1984 game, but this is for the 2000 game (there is also a 2008 game).

&gt; the ADR-50e drive was advertised as compatible, but there was a cave-at<p>I&#x27;m assuming the use of &quot;cave-at&quot; means the author has inferred an etymology of &quot;caveat&quot; being made up of &quot;cave&quot; and &quot;at&quot;, as in: this guarantee has a limit beyond which we cannot keep our promises, if we ever find ourselves AT that point then we&#x27;re going to CAVE. (As in cave in, meaning give up.) I can&#x27;t think of any other explanation of the odd punctuation. Really quite charming, I&#x27;m sure I&#x27;ve made similar inferences in the past and ended up spelling or pronouncing a word completely wrong until I found out where it really comes from. There&#x27;s an introverted cosiness to this kind of usage, like someone who has gained a whole load of knowledge and vocabulary from quietly reading books without having someone else around to speak things out loud.

Truly noble effort. Hopefully the writeup and the tools will save others much heartbreak.

Wow, that backup software sounds like garbage. Why not just use tar? Why would anyone reinvent that wheel?

Is there way to read magnetic tapes like these in such a way as to get the raw magnetic flux at high resolution?<p>It seems like it would be easier to process old magnetic tapes by imaging them and then applying signal processing rather than finding working tape drives with functioning rollers. Most of the time, you&#x27;re not worried about tape speed since you&#x27;re just doing recovery read rather than read&#x2F;write operations. So, a slow but accurate operation seems like it would be a boon for these kinds of things.

F2 was a really neat game. It almost invented Crypt of the Necrodancer’s genre decades early.<p>It’s a little sad that it took such a monumental effort to bring the source code back from the brink of loss. It’s times like that that should inspire lawmakers to void copyright in the case that the copyright holders can’t produce the thing they’re claiming copyright over.

Heh, I remember playing .mp3 files directly from QIC-80 tapes, somewhere around 1996. One tape could store about 120 MB, which is equal to about two compact discs&#x27; worth of audio. The noise of the tape drive was slightly annoying, though. And it made me appreciate what the &#x27;t&#x27; in &#x27;tar&#x27; stands for.

This is just random, but reading this and the backup discussion made me think about SGI IRIX and how it could do incremental backups.<p>One option was to specify a set of files, and that spec could just be a directory. Once done, the system built a mini filesystem and would write that to tape.<p>XFS was the filesystem in use at the time I was doing systems level archival.<p>On restores, each tape, each record was a complete filesystem.<p>One could do it in place and literally see the whole filesystem build up and change as each record was added. Or, restore to an empty directory and you get whatever was in that record.<p>That decision was not as information dense as others could be, but it was nice and as easy as it was robust.<p>What our team did to back up some data managed engineering software was perform a full system backup every week, maybe two. Then incrementals every day, written twice to the tape.<p>Over time, full backups were made and sent off site. One made on a fresh tape, another made on a tape that needed to be cycled out of the system before it aged out. New, fresh tapes entered the cycle every time one aged out.<p>Restores were done to temp storage and rather than try and get a specific file, it was almost always easier to just restore the whole filesystem and then copy the desired file from there into its home location. The incrementals were not huge usually. Once in a while they got really big due to some maintenance type operation touching a ton of files.<p>The nifty thing was no real need for a catalog. All one needed was the date to know which tapes were needed.<p>Given the date, grab the tapes, run a script and go get coffee and then talk to the user needing data recovery to better understand what might be needed. Most of the time the tapes were read and the partial filesystem was sitting there ready to go right about the time those processes completed.<p>Having each archive, even if it were a single file, contain a filesystem data set was really easy to use and manage. Loved it.

A few months ago I was looking for an external backup drive and thought that SSD would be great because it&#x27;s fast and shock resistant. Years ago I killed a Macbook Pro HD by throwing it on my bed from few inches high. Then I read a comment on Amazon about SSD losing information when unpowered for a long time. I couldn&#x27;t find any quick confirmation in the product page, took me a few hours of research to find some paper about this phenomenon. If I remember correctly it takes a few weeks for the stored SSD to start losing its data. So I bought a mechanical HD.<p>Another tech tip is not buying 2 backup devices from the same batch or even the same model. Chances being these will fail in the same way.

CD-R drives were already common in 2001: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;CD-R" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;CD-R</a><p>I wonder would a CD-R disk retain data for these 22 years?

On the topic of Froggers, I enjoyed <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=FCnjMWhCOcA">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=FCnjMWhCOcA</a>

This brings back (unpleasant) memories. I remember trying to get those tape drives working with FreeBSD back in 1999, and it going nowhere.

This will be fun in 20 years, trying recover &#x27;cloud&#x27; backups from servers found in some warehouse.

I&#x27;m pretty sure that even with the substantial damage done by the recovery company, a professional team like Kroll Ontrack can still recover the complete tape data, although it probably won&#x27;t be cheap.

As the other comment here says, any company claiming to do data recovery, and damaging the original media to that extent, should be named and shamed. I can believe that DR companies have generic drives and heads to read tapes of any format they come across, but even if they couldn&#x27;t figure out how the data was encoded, there was absolutely no need to cut and splice the tape. I suspect they did that just out of anger at not likely being able to recover anything (and thus having spent a bunch of time for no profit.)<p>Melted pinch rollers are not uncommon and there are plenty of other (mostly audio) equipment with similar problems and solutions --- dimensions are not absolutely critical and suitable replacements&#x2F;substitutes are available.<p>As an aside, I think that prominent &quot;50 Gigabytes&quot; capacity on the tape cartridge, with a small asterisk-note at the bottom saying &quot;Assumes 2:1 compression&quot;, should be outlawed as a deceptive marketing practice. It&#x27;s a good thing HDD and other storage media didn&#x27;t go down that route.

Name and shame the company, you had a personal experience, you have proof. Name and shame. It helps nobody if you don&#x27;t publicize it. Let them defend it, let them say whatever excuse, but your review will stand.

This is a masterful recovery effort. The README should be shared as an object lesson far and wide to every data restoration and archival service around.

I’ve been suffering through something similar with a DLT IV tape from 1999. Luckily I didn’t send out to the data recovery company. But still unsuccessful.

Is anyone else calling it “froggering&#x2F;to frogger” if they have to cross a bigger street by foot without a dedicated crossing?

DVDs should not be overlooked for backup. The Millennium type have been simulated to withstand 1,000 years.

The author has fantastic endurance, what a marathon to get the files of the tape.

Someone was wise enough to erase the evidence in Party.

<i>Yet, despite ARCserve showing a popup which says &quot;Restoration Successful&quot;, it restores up to the first 32KB of every file on the tape, but NO MORE.&quot;<p>From 10,000 feet, this sounds suspiciously like ARCserve is reading a single tape block or transfer buffer&#x27;s worth of data for each file, writing out the result, then failing and proceeding to the next file.<p>Success popup notwithstanding, I&#x27;d expect to find errors in either the ARCserve or Windows event logs in this case — were there none?<p>While it&#x27;s been decades since I&#x27;ve dealt with ARCserve specifically, I&#x27;ve seen similar behavior caused by any number of things. Off the top of my head,<p>(1) Incompatibilities between OS &#x2F; backup software &#x2F; HBA driver &#x2F; tape driver.<p>In particular, if you&#x27;re using a version of Windows much newer than Windows 2000, try a newer version of ARCserve.<p>In the absence of specific guidance, I&#x27;d probably start with the </i>second* ARCserve version that officially supports Windows Server 2003:<p>(a) Server 2003 made changes to the SCSI driver architecture that may not be 100% compatible with older software.<p>(b) The second release will likely fix any serious Server 2003 feature-related bugs the first compatible version may have shipped with, without needing to install post-release patches that may be hard to find today.<p>(b) Significantly newer ARCserve versions are more likely to introduce tape drive &#x2F; tape format incompatibilities of their own.<p>(2) Backup software or HBA driver settings incompatible with the hardware configuration (<i>e.g.,</i> if ARCserve allows it, try reducing the tape drive transfer buffer size or switching from fixed block (= multiple tape blocks per transfer) to variable block (= single tape block per transfer) mode; if using an Adaptec HBA, try increasing the value of &#x2F;MAXIMUMSGLIST[1]).<p>(3) Shitty modern HBA driver support for tape (and, more generally, non-disk) devices.<p>For example, modern Adaptec Windows HBA drivers have trouble with large tape block sizes that AFAIK cannot be resolved with configuration changes (though 32 kB blocks, as likely seen here, should be fine).<p>In my experience with PCIe SCSI HBAs, LSI adapters are more likely to work with arbitrary non-disk devices and software out-of-the-box, whereas Adaptec HBAs often require registry tweaks for &quot;unusual&quot; circumstances (large transfer sizes; concurrent I&#x2F;O to &gt;&gt;2 tape devices; using passthrough to support devices that lack Windows drivers, especially older, pre-SCSI 2 devices), assuming they can be made to work at all.<p>LSI20320IE PCIe adapters are readily available for $50 or less on eBay and, in my experience, work well for most &quot;legacy&quot; applications.<p>(To be fair to Adaptec, I&#x27;ve had nothing but good experiences using their adapters for &quot;typical&quot; applications: arbitrary disk I&#x2F;O, tape backup to popular drive types, CD&#x2F;DVD-R applications not involving concurrent I&#x2F;O to many targets, etc.)<p>(4) Misconfigured or otherwise flaky SCSI bus.<p>In particular, if you&#x27;re connecting a tape drive with a narrow (50-pin) SCSI interface to a wide (68-pin) port on the HBA, make sure the entire bus, including the unused pins, are properly terminated.<p>The easiest way to ensure this is to use a standard 68-pin Ultra320 cable with built-in active LVD&#x2F;SE termination, make sure termination is enabled on the HBA, disabled on the drive, that the opposite end of the cable from the built-in terminator is connected to the HBA, and, ideally, that the 68-to-50-pin adapter you&#x27;re using to connect the drive to the cable is unterminated.<p>You can also use a 50-pin cable connected to the HBA through a 68-to-50-pin adapter, but then you&#x27;re either relying on the drive properly terminating the bus — which it may or may not do — or else you need an additional (50-pin) terminator for the drive end, which will probably cost as much as a Ultra320 cable with built-in termination (because the latter is a bog-standard part that was commonly bundled with both systems and retail HBA kits).<p>Note that I <i>have</i> seen cases where an incorrect SCSI cable configuration works fine in one application, but fails spectacularly in another, seemingly similar application, or even the same application if the HBA manages to negotiate a faster transfer mode. While this should be far less likely to occur with a modern Ultra160 or Ultra320 HBA, assume nothing until you&#x27;re certain the bus configuration is to spec (and if you&#x27;re using an Ultra2 or lower HBA, consider replacing it).<p>With all that said, reversing the tape format may well be easier than finding a compatible OS &#x2F; ARCserve &#x2F; driver &#x2F; HBA combination.<p>In any case, good job with that, and thanks for publishing source code!<p>[1] <a href="http:&#x2F;&#x2F;download.adaptec.com&#x2F;pdfs&#x2F;readme&#x2F;relnotes_29320lpe.pdf#page=4" rel="nofollow">http:&#x2F;&#x2F;download.adaptec.com&#x2F;pdfs&#x2F;readme&#x2F;relnotes_29320lpe.pd...</a>

At some point, I feel as if it may be easier just to rewrite the code from the ground up vs. going through all that computational archaeology....<p>Or in a few years, just have an AI write the code...

&gt; This is where the story should probably have stopped. Given up and called it a day, right? Maybe, but I care about this data, and I happen to know a thing or two about computers.<p>Hahaha awwwww yeah :muscle: