Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


DavidHertzberg last won the day on January 11

DavidHertzberg had the most liked content!

Community Reputation

74 Excellent

About DavidHertzberg

  • Rank
    Occasional Forum Poster

Profile Information

  • Gender
  • Location
    New York, NY
  • Interests
    Retired applications programmer, with a few Macs at home.

Recent Profile Visitors

2,398 profile views
  1. oslomike, Based on announcements made at the time of its 2019 acquisition by StorCentric, Retrospect Inc. had about 20 employees—with most working from home. It has never in its 30-year history had any hardware-related capability. In fact before Dantz Development Corp. was acquired by EMC in 2004, Dantz used to get driver source code from the manufacturers of various kinds of tape drives—and hire contractors to rewrite that code so it would interface with Retrospect Mac and Windows. That's how Retrospect at the time of its acquisition by EMC had cornered 90% of the market for Mac backup software, and more Windows users than Mac users. (EMC end-of-lifed Retrospect Mac after disk-destination Time Machine was released.) Sometimes the manufacturer's driver code would have bugs, and sometimes the contractors would introduce bugs—which is probably why Retrospect Mac 6.1 can't use the hardware compression capability of my HP DAT72 tape drive. A lot of Retrospect's terrible reputation among IT old-timers, which they've expressed to me in my 4-year-old Retrospect thread on the Ars Technica Mac forum, results from the defects of its tape drivers—note that the linked-to post says another app's AIT driver worked better. It sounds as if there might be a bug in the Retrospect Mac 10.5 AIT driver code, although it might use an AIT driver provided by Apple in later versions of Mac OS X. Your idea of copying your AIT Tape Backup Set to an LTO tape using Retrospect Mac 6.1 is excellent, because LTO is an industry-standard tape format with less flexibility for drive manufacturers.
  2. oslomike, I, too, don't have any knowledge of "inexpensive data recovery companies in the UK that specialise in tape recovery". However you could easily get a quotation from this company, by clicking the "Get a quotation" button on the web page and filling in the details—which include an explanation of your problem. That page sounds as if they might have special software that can copy your one particular AIT tape that has a problem and put a proper end-of-file marker on the copy—regardless of Retrospect's proprietary format, assuming the EOF marker is what you want to know about.
  3. DavidHertzberg

    Ignore Preboot, Update and VM?

    denno, I don't use Proactive scripts; just ordinary Backup scripts. My MacBook Pro "client" is also still booting macOS 10.13 High Sierra, whereas you're probably booting a more-modern version. However I have one suggestion that has worked for me. In the Sources category entry for "SAR MacBook Air", click the Options tab and look at the Back Up pop-up menu on the lower-left of the panel. You probably want to set that pop-up to Startup Volume. If you want to try backing up the "VM" and "Client" and "Update" volumes on "SAR MacBook Air", you could instead try setting that pop-up to Selected Volumes and check-marking the volumes you want to back up. If neither of those settings works, you might be able to solve the problem if you are willing to wait to back up "SAR MacBook Air" until you have plugged it into an Ethernet cable connected—directly or indirectly (through a switch) to your LAN router. You would get its MAC address in About This Mac->System Report->Ethernet->(select card if you have more than one), and create a fixed IP address (some people call that a static IP address) for that MAC address in your router; the method for doing that varies with the router brand and model—ask the ISP that "gave" it to you. However if you insist on having a "poor wandering laptop" connecting to your LAN only with WiFi, you could try either of the two approaches in this post in the Windows–Professional Forum. As Nigel Smith points out in the post directly below that one, they work for a macOS "client" even though they don't work for a Windows "client". After a number of posts discussing the -530 problem for Windows "clients", I said in this post that I had filed Support Case #75559 embodying my suggestions. Feel free to mention it by number in any Support Case you file; Retrospect "Inc." is darned well going to have to solve this problem when they release Retrospect 18.x with the option for a StorCentric Drobo/Linux "backup server" in Spring 2021. P.S.: I had thought about what Nigel Smith says in the post directly below, but had decided "Nah, Denno couldn't be having connection problems after his/her laptop triggers its Proactive script". I thus violated one of my rules for answering Forums questions, which is to look at the administrator's past posts. Lo and behold, this OP about 8 months ago says "All 3 computers are on my home wifi network". Denno should try what Nigel Smith suggests, then start a thread in this Ars Technica Networking forum. Warning: Those experts will be rough on any poster who doesn't supply complete information, so Denno shouldn't try to pull any of the "I don't want to supply complete information because ... security ..." or "I don't want to supply complete information because my employer/clients might recognize me" stunts administrators try to pull when posting in these Forums.
  4. DavidHertzberg

    Retrospect 7.7: Recovery with backup-media

    mcmeini, What I've called the squeaky-clean approach to locating Members of a Backup Set—which you've evidently now followed and which Lennart_T understands—is described in the second paragraph of this post in a Retrospect Mac 9+ Forums thread. Just ignore what I said about the zero-byte "marker" file; further experiments per the first paragraph of this post further down that thread showed that the "marker" file has only a very restricted purpose. That purpose is to exclude destination Members from a Backup or Duplicate operation; they should be copied with Transfer operations. That post further down that thread, and the post below it, describes non-squeaky-clean approaches which my experiments show administrators can use for Member destination positioning. It's unfortunate Retrospect Inc. never put a thorough explanation into the User's Guides. BTW, Lennart_T, how many languages do you speak? I'm impressed. 😀
  5. oslomike, Was the Tape Backup Set that contains the "bad" tape originally written with the Exabyte drive? I'm guessing that this may be so if the Backup Set was created by v4 or v5; the timeline of Retrospect Mac releases at the bottom of this Retrospect History article versus the Wikipedia timeline for the release of AIT-2 seems to show that a Backup Set written up through 1999 couldn't have been written on your AIT-2 drive. Therefore, if you still have it lying around, I suggest you try re-reading the tapes in that Backup Set using your old Exabyte drive. I'm not an expert, but differences in mechanical skew between drives can make tapes written on one drive hard to read on another—especially for special characters such as end-of-tape markers. Let me tell you a tape story: In 1969 I was working as a programmer at ITT Data Services in Paramus NJ, and my boss asked me to write a program to read "gapless" tapes on the IBM S/360 DOS computer at our satellite Lakehurst office and copy them to ordinary "gapped" tapes. The "gapless" tapes were being written by the U.S. Navy's Lakehurst Naval Air Station (that's where the Hindenburg dirigible caught fire in 1937), using a tape drive attached to a radio-telemetry receiver that had no ability to store received data while an inter-block gap was being written. LNAS could read these "gapless" tapes using a Control Data minicomputer connected to a special tape drive that could somehow "stop in less than 2 inches and navigate backwards to before the stop", but the minicomputer had such a pitifully-small main memory (4K 12-bit words) that the LNAS engineers (testing top-secret aircraft; don't ask 🙄 ) couldn't do any real analysis on it. The engineers wanted ITT to copy such tapes onto "gapped" ones that could be read by an ordinary tape drive on one of ITT's 512KB OS/360 IBM mainframe computers in Paramus. I wrote a tricky copy program in S/360 DOS Assembler, and it worked successfully on a test tape. However it turned out that the LNAS tape drive attached to the radio-telemetry receiver had a skewed read-write head, and the Control Data minicomputer's tape drive read-write head had been skewed to match. ITT wasn't willing to skew one of its satellite-office IBM tape drives to match, so my program never got used in production. See an audio expert for an explanation of tape skew.
  6. oslomike, Lennart_T is correct; neither your OP or subsequent posts made it clear that you were encountering the problem with the tape during a Rebuild of a Catalog for a AIT Tape Backup Set—I thought it was during a Transfer of that Backup Set to a v6.1 Backup Set. I also thought you were having this problem using Retrospect Mac 6.1 on your old Mac Pro (2,1). It wasn't until I read this recent post in one of your other threads that I realized you have connected your Exabyte AIT tape drive to your newer Mac Pro (5,1), so you are encountering these problems running macOS 10.13 High Sierra—as you've said in a recent post in the second of your other threads. Naturally the suggestion now occurs to me that you should move your AIT tape drive—and the ATTO SCSI PCI card it's connected to—back to your old Mac Pro (2,1), and try Rebuilding the lost Catalog for that AIT Tape Backup Set on your old machine. If you can do so including the "bad" first tape (which might only have a bad end-of-data marker when it is read by Retrospect Mac 10.5 under High Sierra; there could have been some limitation in the AIT-drive-handling code), then do a Transfer of all 3 tapes to an LTO Tape Backup Set on the old machine, and copy that complete LTO Tape Backup Set on the new machine—to an LTO Tape Media Set. If OTOH you still get the error on the "bad" tape, then temporarily postpone copying the "bad" tape by doing what I said in the second paragraph of this up-thread post—with the Transfer of the incomplete AIT Backup Set being to an LTO Tape Backup Set . After drafting the above paragraphs I went to dinner, and came back to find you had made another post (up past your Norwegian bedtime, aren't you? 😲). Frankly I'm getting rather annoyed, oslomike, with your systematic refusal to clarify in this thread which of your two machines you're talking about. 🤢 I'm here to help you, not to play guessing games. Returning to the final sentence of my third long paragraph above—if the AIT tape turns out to be "bad" when read on both machines, you could later do one of two things to accomplish what you're asking Lennart_T how to do in the third sentence of the post directly above this—depending on whether Retrospect will quit when run on your old Mac Pro (2,1). If it will quit on your Mac Pro(2,1), mark the "bad" tape as Missing from the AIT Tape Backup Set per "The Members Tab" on page 155 of the Retrospect Mac 6 User's Guide and then Rebuild that Backup Set's Catalog with the "good" tapes per "Rebuilding a Catalog"on pages 188–189 of the UG. Alternatively you could try the "Verifying Media Integrity" operation on pages 190–191 of the Mac 6 UG. If it won't quit on your Mac Pro(2,1), first quit the Retrospect Engine on your Mac Pro(5,1) or uninstall it—after making a Finder-copy of the files that are in Library->Application Support->Retrospect , then re-install if necessary—followed by a reverse--Finder-copy of the copied files back into Library->Application Support->Retrospect—and follow the "Verifying a Media Set" procedure on pages 208–210 of the Retrospect Mac 10 User's Guide—doing a Mark Lost for the "bad" tape. After that follow the "Repairing a Media Set" procedure on pages 210–213 of the Mac 10 UG, clicking the Add Member button for each of the "good" tapes—this may not work unless you click Add Member twice to skip over the "bad" tape. This 2012 OP of yours raises a new set of questions because it says "I have this old Exabyte Mammoth LT drive", and the Exabyte Mammoth LT has only SCSI connectors. Yet this very recent post of yours says "I just brought the AIT drive home and it connects via firewire cable". This later 2012 OP of yours says "Retrospect v6.1 on one partition with Leopard running which will be mostly used for a SONY AIT-2 (firewire interface) and an older Exabyte Mammoth LT drive (SCSI 1 interface via ATTO UL5D card)." Does that mean the "bad" tape was written on a different AIT tape drive from the drive on your Mac Pro(5,1) which had trouble reading it? And this CNet page says the interface on the Sony AIT e200-UL is FireWire 400, which means—I also have a Mac Pro (5,1)—that you must be using a FireWire-400-to-800 adapter. Hmmm! 🤔
  7. oslomike, My gut feeling, from having worked extensively with tapes many years ago on IBM mainframes which didn't yet have disk drives, is that you've got an unreadable end-of-data marker on the first tape Member of the input Backup Set. The computer operators—a separate profession in those days—used to have a utility program that could write an end-of-tape marker on a tape, but AFAIK we don't have such a program now. (Some folks may: In 1992 I had backed up my wife's Mac using a Maynard QIC tape drive before I erased her HDD, and the Maynstream backup program—the ancestor of BE—couldn't read the tape to restore it. I paid DriveSavers US$600 to recover the data from the tape, which they did; it'd now cost around US$2000.) If you've got the data from that input tape on the output Backup Set, IMHO what you should do is to run another Transfer to the same output Backup Set using only the remaining tape Members of the input Backup Set—starting with the 2nd one. A way to do that would be to mark the first tape Member of the input Backup Set as Missing, per the NOTE under "The Members Tab" starting at the bottom of the left-hand column on page 155 of the Retrospect Mac 6 User's Guide.
  8. oslomike, First, you haven't said what version of macOS you're running on your Mac Pro (5,1), but on macOS 10.12 Sierra I can stop the Retrospect Mac 16.6 Engine by going to System Preferences->Retrospect (not System Preferences->Retrospect Client, if you've got the Client on the same computer—which I temporarily did a few months ago) and clicking the Stop Retrospect Engine button. However that button remains grayed-out until I first click the "Click the lock to make changes" padlock icon in the lower-left corner of the dialog and enter my machine's password. You can later do the same thing in reverse and click the Start Retrospect Engine button. Second, why do you need to stop the Retrospect Engine? Since Retrospect Mac 8 all operations are run as scripts, even if you've Added a new Copy Media Set script in the Console's Scripts sidebar category and clicked the Run button. So all you need to do is to go to the Console's Activities sidebar category, select the running script you want to stop in the dialog, and click the Stop button at the top of the dialog. Finally, starting with this Nigel Smith post in another thread is a discussion of how to uninstall the Retrospect "backup server" Engine. Below it is a post by me explaining how I first used the Console on my battery-rejuvenated Mac Pro to do "Export server installer and uninstaller" to a thumb drive, so I wouldn't have to Start the Stopped Engine on the MacBook Pro "client" machine on which I had temporarily installed it in order to uninstall it on the MBP.
  9. https://en.wikipedia.org/wiki/Advanced_Intelligent_Tape#AIT_generationsoslomike, First, in your Process B.1 directly above, the Retrospect Mac "backup server"—certainly for the Retrospect Mac 16.6 I use, won't allow Members for any type of Media Set unless each Member has a "label" derived from the name of that Media Set. For a Disk Media Set, that means a Member file name consisting of the Media Set name preceded by a number and a dash (e.g. "1-Media Set Red" for a Member of "Media Set Red"). IIRC the same is true for a Tape Media Set, that means a Member tape label consisting of the Media Set name preceded by a number and a dash (I can't check this because my old Digital Audio G4, which I had been backing up to DAT tape with Retrospect Mac 6.1, stopped being able to boot 2 months ago). AFAIK this Retrospect feature is designed to prevent mistakes in adding Members that shouldn't be part of a particular Media Set. That means your Process B.1 would effectively have to Add a Tape Media Set with the exact same Backup Set name as the one that created the LTO-5 tape(s) whose Catalog it is "rebuilding", with that/those LTO-5 tape(s) as its Member(s). If your Mac Pro (5,1) already has a Media Set with that same name but different Members (e.g. a File Media Set), IMHO the easiest thing might be to Remove that existing Media Set and Finder-delete its Catalog File and its Members. In any case the "rebuild" process would require your Mac Pro (5,1) to actually read the data on each LTO-5 tape, since Retrospect Mac 6.1 did not yet support the Fast Catalog Rebuild feature that writes at the front of each new tape a copy of the Catalog File as it existed before the first file is written to the new tape. Second, I question whether your Process A needs to have step 1 and step 2 in most cases. Given what I've written in the last sentence of the paragraph directly above this one in this post, wouldn't it be sufficient to simplify Process A to the following single step? 1.Using v6.1, Copy v4,v5,v6 non-LTO-5 Tape Backup Sets to v6.1 LTO-5 Tape Backup Sets The description of your Mac Pro (2,1) in the post directly above says your Exabyte—presumably AIT—and DAT tape drives are connected to a different SCSI PCI card on that machine than your LTO-5 drive, and your previous up-thread post implies reading AIT tapes is slower than writing LTO-5 tapes. Of course, in those cases where you've already created v6.1 File Backup Sets, you can just execute your existing step A.2.
  10. oslomike, Yes, if I you can manage to connect a second LTO-5 tape drive to your 6.1 machine, you could (using v6.1 terminology) Transfer v6.1 File Backup Sets to v6.1 Tape Backup Sets. See pages 60–61 of the Retrospect Mac 6 User's Guide for a description of the "Transfer" operation. Unlike Retrospect Mac 8 and onward, where the "Transfer" operation—with its different options—was revised into the Copy Media Set and Copy Backup script types, in v6.1 it is only executable as an Immediate operation. "Setting Transfer Options" on page 61 says it will do what you want, because Don't turn on any of the other options listed under ""Backup Set Transfer Options" on page 145; they would do what you definitely don't want. That's why v8 revised them into a Copy Backup script type—to be used for copying the last (or last few) backups—distinct from the Copy Media Set script type; see pages 153–158 of the Retrospect Mac 10 User's Guide. When you say "copy 10 AIT tapes", I assume you mean the contents of 10 AIT tapes on a File Backup Set—unless your v6.1 machine can have both an AIT tape drive and an LTO tape drive connected at the same time. Can your v10.5 machine either (a) have an LTO-5 tape drive connected or (b) have an LTO-6 or LTO-7 tape drive connected? Either LTO-6 or LTO-7—but not later LTO generations—can read an LTO-5 tape. You wouldn't have to Rebuild the Catalogs of those Tape Backup Sets in v10.5, just Add Tape Media Sets with the same names as the corresponding v6.1 Tape Backup Sets and the appropriate LTO tape(s) as one (or multiple) Member(s)—the Catalogs would be built by the Add process. If you then wanted to copy one or more of these Tape Media Sets as Disk Media Sets (please not, for Heaven's sake, File Media Sets), you'd have to Add Disk Media Sets with similar names and then Run one-shot Copy Media Set scripts to copy the Snapshots and copy the backed-up data from tape to disk. BTW, "intact" is a single word in English. Since Norway didn't have the benefit 🤣 of a Norman French occupation, you may not realize that "intact" is derived—through Middle French—from a single Latin word. Don't feel embarassed; many native English speakers these days make the mistake of splitting the word into two words "in tact" when writing.
  11. oslomike, In view of your first and third paragraphs (after "Hi Nigel") in your post I've quoted here, I don't see why—in your post immediately above this post—"rebuild the v6.1 file sets within v10.5 so that they are at least searchable and fairly easily retrievable" is going to do much for you. All it's going to do is require you to "leave the old machine turned off until needed"—meaning until needed into the far future. How do you know your v6 machine will last into the far future? My 2001 G4 Digital Audio Mac—given to me by my ex-wife—stopped being able to boot about 2 months ago. That's why I suggested, in the final long paragraph of this above post, creating v6 Tape Backup Sets that are readable in v10.5. The last paragraph in your post I've quoted says "I suspect that Retrospect v10.5 was put together to rebuild catalogs only if they were rebuilt from tapes, not File Sets." However I now see that I've ignored the tape hardware generation problem in creating tapes that are writeable in v6 and readable in v10.5. Can you install a SCSI—and I don't mean SAS—interface card in your 10.5 machine to which you can attach the tape drive from your v6 machine? But I've now thought of a further alternative. Instead of trying to Rebuild your v6 File Sets in v10.5, do Copy Media Set operations to convert them to equivalent v10.5 Disk Media Sets. And I don't mean File Media Sets; face up to the fact that File Media Set Catalogs are not fully supported in v10.5 🙁, because in 2012 Retrospect Inc. already considered them to be obsolete relics of the ancient days of small and expensive HDDs. CopyMedia Set scripts are summarized on page 153 and discussed on pages 154–155 of the Retrospect Mac 10 User's Guide. Because "Copy Media Set makes a copy of the backed up data [my emphasis] contained in a source Media Set to a specified destination Media Set", the Catalog File it creates for the destination Disk Media Set should be complete including snapshots. P.S.: If you instead want to get Retrospect enhanced to once again—if it ever did—correctly Rebuild the Catalog File for a File Media Set, here's why and how to request that enhancement. However, in assessing your chances of getting that done for Retrospect 18, consider this: The other day I had to submit a Support Case to get the posts of three obvious spammers removed from the Retrospect Forums. I had already done a "Report post" for each of those spam posts, and in prior years that would have been sufficient to get the removal done, but it seems the head of Tech Support is too busy now to look at posts that administrators have merely reported. Why is he so busy? IMHO both long paragraphs of this post in another thread give the answer to that question—an answer that also applies to the Retrospect "Inc." engineers. Note that the delivery of the interlocking set of major enhancements described in the second long paragraph of that post has evidently now slipped from Retrospect 17.5 to Retrospect 18.x.
  12. Alfrdaf and RonaldRup, My idea is that both of you—based on your preceding posts in this other thread—are actually commercial spammers from Belarus or Western Russia. You are occasionally making posts that sound as if they might be related to the topics of the threads you post in, but close reading of those posts reveals they are not related to the topics. I will continue to report your posts, and will try to get you banned from the Forums. 🙄 P.S.: I had to write a Support Case with Forum Request as the Issue, but I got all posts from Alfrdaf and RonaldRup removed from the Forums. As a result of the same Support Case, all posts by GeorgeHeesy were also removed ; his were giant paragraphs that purported to be about male erection problems, but that were so disordered that they sounded to me—with no background in mental health—as if they were written by a schizophrenic (like a couple of people who occasionally post anonymous documents on the street in my NYC neighborhood).
  13. oslomike, I'm sorry I didn't post this earlier, but sleep overcame me. Meanwhile Nigel Smith, in his ex-EU location (Happy Brexit, Nigel 😄 ), has posted—but he didn't think of the following possible solution still being used as of 2019 by billbobdole of the Engineering School at Texas A & M University. First my analysis, with which I think no one will disagree: As you report directly above, Retrospect Mac 10.5 does not read any associated .cat file when it rebuilds a v6.1 File Backup Set into a v10.5 File Media Set. Therefore the solution might be to break up each of your created-from-Tape v6 File Backup Sets into multiple ones that don't have .cat files—because the snapshots are in the resource fork. Then maybe v10.5 would keep the snapshots when you do a Rebuild. As Nigel has posted, Removable Disk Backup Sets were generalized in v8 into Disk Media Sets—preferable to File Media Sets. (FYI Retrospect Windows still also has Removable Disk Backup Sets, but these should only be used by old-timers clinging to their no-longer-manufactured "superfloppies"; Retrospect Windows administrators often get into trouble defining RDX cartridges as Removable Disks.) How could you accomplish the breaking-up? billbobdole was as of June 2020 still using a trick for File Media Sets, described by twickland in this 2010 post. If you do a New Media backup to a File Backup Set, Retrospect will "Create a new destination file and associated catalog with a subnumber appended to the backup set's name (i.e., [001], [002], etc.)." If you first did a New Media backup using a No Files Selector—page 179 of the Retrospect Mac 6 User's Guide—to create such a File Backup Set with a sub-number appended to its name, and then did a Transfer—pages 60–61—to that same sub-numbered File Backup Set using a custom Selector—pages 180–186—limiting the Transfer to a specific date range, that would create a sub-numbered File Backup Set that could be small enough to have its catalog in the resource fork and need no associated .cat file. Ideally, given what you posted above while I was writing this post, a simpler solution would be to use a v6 Transfer to populate a previously-defined v6 Tape Backup Set with the contents of each v4 or v5 Tape Backup Set. These should be readable by v10.5. However I realized after first posting this that you probably don't have the SCSI interface and drive hardware to attach two different tape drives at the same time to your Mac booting v6. So here's a realistic simple solution: Create a single v6 File Backup Set as large as possible. Then—one Backup Set at a time—Transfer without Selectors each v4 or v5 Tape Backup Set to the single File Backup Set, create a new v6 Tape Backup Set with a name similar to the Transferred v4 or v5 Tape Backup Set, Transfer without Selectors the File Backup Set to the newly-created v6 Tape Backup Set, and finally Recycle the single File Backup Set to clear it for the next Transfer. This saves disk space on your old Mac—also on your new Mac if Tape's OK, but uses more blank tapes. In regards to your thanks below, some of us enjoy solving somewhat-difficult problems for other administrators.😀
  14. oslomike, With regard to the problem you described in this up-thread post, I suggest the following: Move the ATTO SCSI card back to your machine running Retrospect 6, then restore those tapes written by Retrospect 4 and Retrospect 5 to a Subvolume assigned to a temporary folder created on that machine. Next, backup that Subvolume to one or more tapes, which should be readable by Retrospect Mac 10.5. Finally, delete the temporary folder created on the Retrospect 6 machine.
  15. Nigel Smith, You may be right, if the "point in time" was earlier than any backups written to the tape Member "4-Backup Set H". Remember, jbalaska63 complained that that Member and "5-Backup Set H" weren't even mounted by the Restore. That's why I made my first and second suggestions in this up-thread post. Of course the "point in time" might have been earlier than some of the backups on "3-Backup Set H", which was the last tape jbalaska said was mounted. So for safety, if my first suggestion doesn't work, maybe jbalaska63 should extend my second suggestion to the date of the first backup known to have been written to "4-Backup Set H"—a date which may be marked on an external label. Back in the "good old days" of mainframe computers, we used to have "tape dump" programs that would print records from a tape; maybe Retrospect Tech Support can supply one, along with an outline of the format of tape label and backup data records.