Jump to content

prl

Members
  • Content count

    275
  • Joined

  • Last visited

  • Days Won

    3

prl last won the day on November 25 2013

prl had the most liked content!

Community Reputation

13 Good

About prl

  • Rank
    frequent Poster
  1. OK. The copy finished and I got around to testing the copy. I can navigate into the copied directory for a Verify, but when I select the data member, it goes straight back to wanting me to Choose Media again, without putting anything useful into the log. Also, very oddly, when the top level directory of the copy is called "NewRetro", I can navigate in the directories inside it, but if I rename it to "Retrospect" (the original name), I can no longer navigate inside it. Also, When the old copy is renamed from its original name "Retrospect", to "OldRetro", I can navigate into its directories, but a Verify of its members fails in the same way as the Verify of the copy. Looks like I'll need to set up new backups.
  2. I tried doing a partial copy of one of the disk media sets, and it seemed to be accessible from Retrospect. I'm currently doing a full copy of both disk media sets. It's s.l.o.w. I'll let you know how it goes. Thanks for the suggestion. It's still no clearer why two long-functioning media sets decided to "disappear" from retrospect.
  3. OK, I tried making a new backup into a directory that Retrospect had newly created on the NAS, and it all worked just fine. I then renamed that directory to the name of the original backup top level directory and moved the backup set directories into it, but still no good. I think I'll abandon the old backup sets and create new ones. All a bit annoying.
  4. Thanks for the suggestion, but from Retrospect>About: "Version 16.1.2 (102)". So no luck there. Nigel, thanks for your suggestion. I haven't had time to try it out yet, but I will. I may also try moving the existing backup members to another directory on the NAS, too. The NAS doesn't have much in the way of permission control. Only registering users with passwords, specifying the name of the directory subtrees that are exported to them and whether they have read or write permission. The NAS feature of the router seems to have been a bit of an "oh, look, there's room for Samba, so let's put it in" effort. It was removed a while back for space reasons, but there were enough user grumbles that they found space for it again.
  5. Since installing 16.1.2, I haven't been able to do backups to disk media sets on a NAS. Now, when the backup wants to start writing to the media set, it goes to Needs media, and when I use Choose Media..., I can navigate down into the top levels of the NAS filesystem, but when I get to the directory that contains the top-level directory of the disk that contains the media set members, I can open and display some directories, but not the Retrospect directory that contains the backup members. I get similar results when I try to use Verify on the backup set, or to create a new backup set on the NAS. I can access the directories where the Retrospect stored the media sets in Finder (as myself) and by using U*ix commandline access to list the directories both as myself and when su'd to root (which RetrospectEngine runs as). This all worked for several years before I upgraded to 16.1. Anyone have any ideas? Retrospect for Mac 16.1.2 (102) MacOS 10.11.6 (Please don't suggest that I upgrade - my Mac is a MacBook Pro 13-inch, Mid 2009, and this is the most recent MacOS version that runs on it) NAS: SMB shares served from a Fritz!Box 7390 router (yes, it's slow, but it worked until the Retrospect upgrade)
  6. Has anyone tried using a Pioneer BDR-XS06T Blu-Ray drive (or any close relatives) with Retrospect on a Mac?
  7.   I think that one means that there are bits missing in a block-wise incremental backup. I've seen a similar problem before in an earlier version, the last update to v13, I think.
  8. I thought it would be that way.
  9. Can block-incremental backups made in v11 be restored by earlier versions? I'd assume not.
  10. Retrospect can back up files on the Server, not just Clients. The interface for backing up files on the Server is different to the interface for backing up files on Clients, so this isn't just a trivial distinction.
  11. Hi, Mark. What you describe that you do is what I meant by manual backups. If you do all your backups like this, you may as well turn off Instant Scan. IIRC, Instant Scan only processses file system changes about once every 5 minutes. I have no idea why that choice was made. That meant that people who'd just made a file modification and then ran a manual backup wouldn't have the recently changed file backed up. So Instant Scan is only used for scheduled backups. See David W Lee's explanation of the process here. IMO, this is the wrong fix, but I'm not sure what the rationale was for the delay on processing Instant Scan files. It seems to me that someone who knows what the backup schedule is and does the file change just before they "know" when the backup will be done will be in the same situation of thinking the backup will be back up their recently changed file, but the backup won't actually happen. I was quite disappointed that I'm unable to use Instant Scan for my manual backups. They could at least have documented the delay in the Instant Scan process, and allowed users to make their own decision about whether to use Instant Scan for manual backups.
  12. RetroISA is short for something like Retrospect Instant Scan Agent (not sure about the 'A'). It's the process that listens for file system updates and generates a list of files to be backed up so that the "scan" part of backups can be "instant", since it already has a list of files to back up. The Retrospect documentation is pretty light on how it works. The Instant Scan data is never used for manual backups, so if, like me, you only do backups manually, there's no point enabling Instant Scan.
  13. When is Retrospect going to do something to make that "additional error information" actually useful for something? I've tried Google Translate on it. Doesn't help. It's been like that for as long as I can remember.
  14. prl

    LTO-6 and crypting

    If you encrypt in software and compress on the drive (or do anything that encrypts first, then compresses), the compression won't work. It's pretty much impossible to compress data that's been through even half-way good encryption.
  15. I thought that any grooming potentially removed data.
×