Jump to content

Nigel Smith

  • Content count

  • Joined

  • Last visited

  • Days Won


Nigel Smith last won the day on January 18

Nigel Smith had the most liked content!

Community Reputation

27 Excellent

About Nigel Smith

  • Rank
    Retrospect Junkie

Profile Information

  • Location

Recent Profile Visitors

857 profile views
  1. Exactly the same (I deliberately created them with separate catalog files, to match your situation). The v6 catalog file will be ignored -- this is a "rebuild", which starts from scratch and reconstructs the backup using only the data file, rather than a "repair". Try the alternate route -- attempt a "Restore" operation on the v10 set and use the "More Backups..." button to see if they are shown. Or, simply give up 😉 Do you really need to do a "point in time" restore of a whole volume from x years ago? If not, you can likely do what you'll need by simply using filters on the whole set -- eg "all files and sub-folders in the Important Project folder last modified in 2010" then manually selecting what to restore from the results.
  2. Sorry, I didn't make my point very well (or, indeed, at all!). We often use "backup" and "archive" interchangeably, but you may find it helpful to consider them as two different things -- "backup" for recovery (disk failure, wrongly deleted files, reverting to a previous version), "archive" for long-term storage of data you want to keep. In many ways this is a false dichotomy -- you may need to keep your backups long-term (eg compliance) and you can restore files from your archive -- but it can help from a management POV to keep the two separate. Of course, being a belt-and-braces type guy, I'd then archive my backups and make sure my archive was backed up 🙂 More copies are good! It's really a data management/business rules thing. It helps us because we tend to work on projects (or by person) so when the project is finished (or the person leaves) all associated data can be archived, keeping it in a single place while also freeing up resources on the "live" systems. YMMV. It doesn't really matter whether you use DAS, NAS, a bunch of drives in a cupboard that you plug in when needed -- whatever works for you! NAS is more expensive per TB than comparable DAS because you are paying for the computer that "runs" it as well as the storage, but because it is a complete "system" you can take advantage of in-built scheduled disk-scrubbing etc rather than having to roll your own health checks on DAS. But if your RAID is a SAN it probably has those already -- in many ways, a NAS is just a poor man's SAN 😉 But the best system is the one that works for you. Managing data is a necessity but, after a certain point, can cost more than it's worth to your business. Only you know where that point is and how best to get there.
  3. No magic -- just LaunchDaemon doing its thing. From the Engine's plist: <key>KeepAlive</key> <true/> So if you want to force-quit the RS Engine you'll have to unload the LaunchDaemon plist first. Untried, but sudo launchctl unload /Library/LaunchDaemons/com.retrospect.retroengine.plist ...in Terminal will probably (I'm looking at v13) do the trick.
  4. Then, tbh, you need a better system for archiving that data. Like with backups (and I draw a distinction between archive and backup), you should be thinking "3-2-1" -- 3 copies on 2 different media with 1 offsite and, importantly, you should be rotating your archives on to new media more often you have been. High-resilience disk-based storage is relatively cheap and you should use that for your "primary" archive copy. Don't forget to check application versions etc -- you may be near the point where you'll need to re-write old data to new formats... I wouldn't know -- and I'm not sure I'd trust anything over Retrospect for recovering RS's proprietary format (tar tapes would be a different matter). Best to avoid any problems with "3-2-1", media rotation, regular checks that you can retrieve files, and so on.
  5. Don't know about best, but what I'd try is: Rebuild to "tapeset1", starting with the first tape, expecting it to fail at the end of the tape as you've described Rebuild to "tapeset2", starting with the first tape, expecting it to fail... Take tape 1 out of the drive! Repair "tapeset2" and, when it says insert tape 1, mark tape 1 as missing and continue with tapes 2 and 3 You've now got the most data back that you can, albeit in two sets. You could then try and combine them by copying "tapeset1" to a new "diskset1", then "tapeset2" to that "diskset1" -- "diskset1" can then be moved to your newer machine for the conversion. Your choice as to whether "diskset1" is a File Set or Removable Media Set. You could, perhaps should, copy the two tape sets to two disk sets, convert them to the new format, then combine them -- it'll take longer but might be "safer". I'd also start to wonder about the chances of me ever needing to go back to data from 10+ years ago and whether it's worth all this extra work! That'd be a struggle between my innate laziness and my OCD, but you may have compliance issues to satisfy.
  6. I won't claim it's best -- but it's what works for me! Meanwhile, I've run some tests -- and I am getting snapshots transferred in a v6 File Set conversion. Couple of wrinkles: The File Sets were created in RS v6.1.230 rather than transferred from tape The conversion was done with RS v13.5 -- the closest I have to v10 on hand Only one snapshot is shown in the rebuilt set until you go to "Media Sets", select the rebuilt set, select the "Backups" tab, and use the "Retrieve..." button to show the others. Alternatively you can use the "Restore" wizard, select the single-snapshot set, and use the "More Backups..." button to show the other snapshots. So the snapshots are transferred. Whether that's because I'm using a different converting version of RS, a different workflow, or just delving deeper into the end result to find them -- who knows?
  7. I tend to play it safe, and create the new media set myself rather than relying on the software -- mainly because it gives me extra chances to check the name, settings, etc! Finally got to go in to work this week, so I've fired up the old v6 server and I'll do some test wrt snapshots and the v6 set conversion.
  8. That log actually suggests that the scan is failing during the "SAR MacBook Air" operation because of a network disconnect and it then can't access the other APFS volume groups because the laptop isn't on the network -- they're a symptom, not a cause, so omitting them won't help. Solve the network problem. I'd start by defining a small "Favourite" folder, seeing if that works, then expanding. It might be a time-based issue, eg aggressive sleep settings, maybe a dodgy drive, or something else -- so I'm afraid you've some troubleshooting ahead...
  9. They were called "Removable Disk Backup Sets" back then. Their main advantages over "File Backup Sets" is that they can span media and can be larger than the maximum file size permitted by your OS. "Removable" sets store their catalog separately, "File" sets store the catalog in the file's resource fork until that exceeds the OS's resource fork size limit (16MB) at which time it is split out into a separate file, which is what you are seeing. Check your v6 "File" set. Does that have snapshots? It may be that you are losing them in the v6 tape->file part of the process, and not during the v10 rebuild.
  10. Nigel Smith

    locate cloud media set on new retro server?

    Your guess was perfect! IIRC from my testing, each client/volume (volume can also be a Favorite Folder) combo gets its own "container" in the Storage Group. If you'd called the new Server "FileServer" and the volume/Favorite in that "VMFS03_Helios" then RS might have carried on with the same container and not doubled up your data but, as you've seen, there's no dedup across containers. Storage Groups aren't appropriate for what you are trying to do -- they're really a way to parallelise multiple slow backup streams from different clients to a (pseudo) single set. Use a cloud-stored Disk Media Set instead. You might be able to retain continuity by migrating your Storage Set backups to the new Disk Media Set using "Copy Media Set" scripts, but you'll probably be paying ingress/egress fees on all that data all over again...
  11. IIRC, you have have to go from vWhatever -> v6 -> v10. In v10, try using Backup Assistant and selecting "Search for files in selected media sets" in step 1. Then, in the "Search Files and Folders" dialog, use "Any" and "File Name contains" but leave the text box empty (see pp 142-145 of the v10 User Guide). Do check carefully -- run Restore Assistant on the rebuilt set and see if the "More Backups..." button gives access to the "missing" snapshots. But I honestly don't know. My experience is with v6 Internet Backup sets, which can't be converted, so I've been doing full v6 restores (including every versioned file) of every client and then backing up those restore folders with the newer RS version. I'd hope it would work, but if your experience says otherwise you should trust it! But do you need to do point-in-time restores from those old sets? I have no need of recreating an hard drive from 10 years ago but I do need to be able to eg pull back original experimental data if it is ever questioned -- your actual needs may also make snapshot retrieval unnecessary.
  12. Nigel Smith

    locate cloud media set on new retro server?

    Sorry -- my stupidity. Of course the "Locate" command is used to point to the catalog file. D'oh! Can you post the paths of the two Backblaze Storage Group directories for the same backup client? Might be a clue there...
  13. Do a search with both the "Include" and "Exclude" boxes empty -- that should return every file that was ever backed up. You should be able to re-catalog the tapes in 10.5, then directly "Copy Media Set" from tape to a new disk media set, retaining all snapshot information etc.
  14. Nigel Smith

    locate cloud media set on new retro server?

    When you used "Locate", what did you select? I haven't used a cloud target, but I suspect it is the same as a mounted-NAS target and you should be selecting the volume/directory that contains the "Retrospect" directory that holds your backups, not the "Retrospect" directory itself. (I often get that wrong, usually with the results you describe!)
  15. It's probably comms with the tape drive that are causing the problem, but make sure by disabling the iSCSI initiator, turning off the drive, turning off the RS Engine auto-start, rebooting the Mac, waiting 5 minutes (for log messaging to settle), manually starting the RS Engine and then launching console. (Manually starting the Engine gives you a known time-point for you to check the system logs.) If all is good, do the same but this time with the iSCSI initiator enabled. Then the same but with the tape drive turned on. I'm betting it'll reproduce the problem in the last test. As David suggests, you should try again with the drive on but the iSCSI initiator disabled, just to be sure there's no clash there. Then we're on to details -- SAS card, tape drive type, make sure card and drive firmware are correct for your OS and Retrospect, re-seat the SAS card, try a different cable, etc.