All Activity

Does the external USB drive have anything to do with Retrospect? (Such as being part of a disk backup set.) Otherwise I have no idea. Sorry. I never experienced this problem myself.

This is not an easy fix. Windows tends to touch folder modify timestamps when anything inside is touched. Best solution I have found: occasionally run a good tool to reset the timestamps to the newest-change in nested folders underneath. NirSoft has a nice free one that's very fast on Windows. FolderTimeUpdate

It would not surprise me if this issue were related to the (AFAIK still unresolved) challenging problem I discovered several years ago. I will describe it by explaining how to test for it: download and install NirSoft's TCPview app. Open the app and sort on Local Port You should see retroclient.exe listening on port 497 -- that is normal At least one line will listen on 127.0.0.1 (localhost) which is fine. That's internal to the app You should ALSO see retroclient listening on your real IP address. E.g. 192.168.x.x or whatever. -- if so, that too is fine. The problem: under various circumstances, anything from a stale WiFi link to one or more Windows virtual network devices can produce an IP address that goes nowhere. Usually this is an APIPA address (169.254.*.*)... and retroclient can listen on that instead of the real IP address. So far I've not seen it necessary to reboot, just restart retroclient with a pause. I have a batch file that does: net stop "retrospect client" sleep 3 net start "retrospect client"

On my Win10 computer running Retrospect (18.5 -- upgrade coming as soon as paperwork is received)... The computer has four specific partitions backed up (C:, D:, P:, Y:) I plugged in an external USB drive, with multiple partitions Windows will not let me eject it because it is busy I traced the issue (System Event Viewer, filter for event type 225!) to Restrospect.exe refusing to let go In Retrospect Volumes Database, every partition on the USB shows up. There are two painful issues: "Forget" is grayed out. I cannot tell Retrospect to ignore specific USB partitions I don't see a way to generally ignore USB devices. This is HUGE since Retrospect grabs any USB device and won't let go! I do NOT need all USB sticks backed up. The only workaround I see at the moment is to stop Retrospect when I need to eject a USB device. That's pretty obscure (it was NOT obvious that the culprit was Retrospect!) Does anyone have a better solution?

Sorry for the bump of this old thread. I recently found the cause and workaround and just wanted to share it just in case anyone else is wondering or googling this. A couple months ago, I accidentally learned that a Windows shutdown and restart is actually not the same as doing a reboot. This is due to a feature called 'Fast Startup' which performs a sort of hybernate when doing a shutdown, which then speeds up a subsequent startup. This is a recommended setting (per Microsoft) and is also on by default. However, that difference with a reboot immediately made me think of the Retrospect issue I had and which is described in this thread. So I actually turned off Fast Startup on all my Windows PCs (both 10 and 11). In fact, many articles do recommend turning this off so your system has a proper shutdown and boot up. Well, you probably already guessed it: since I turned off Fast Startup on all machines, I have not run into this Retrospect issue a single time. All my pro-active backups are now running reliably and whenever they should. I'm surprised that Retrospect Support themselves were not aware of this issue, and that it took me several years to find out. But better late than never, I guess.

I've run into the painful catalog rebuild -> failed groom cycle. I saw the advice to set ForceThoroughRebuild=1 in retro.ini and followed it. Yet, the next rebuild (yes after restarting Retrospect) is doing a Fast Rebuild. Have others run into this? Is that feature brand new somehow? (The setting has been there for many years; perhaps a placeholder???)

Hi, Last weekend I set up a new computer running macOS V14.4 and used Migration Assistant to move my applications from the old machine (running macOS V12.7.4 and Retrospect V19.2). I went to make a new backup set using a new external hard drive. When I went to make the initial backup I got an error about Retrospect not having access to the new hard drive. Both my user account and Administrator have R/W access to the drive. I thought it would be a simple matter to set up this script (select Source, Media Set and execute) but something just isn't right. At this point I'd prefer to just completely uninstall Retrospect and re-install from scratch. But, I can't find a mechanism to do that from any of the installers that I've saved. I found an option in the Preferences/Console tab to export the client/server installers and the Uninstall Retrospect app. Does this uninstaller remove all traces of Retrospect (which is my goal)? Thanks in advance, Alan P.S. Alternatively, if anyone knows why my external drive is considered off limits to Retrospect and how to fix that, that would be very helpful.

Hi, my log file is flooded with: [!] Provider::proGetProv: Provider cannot make a provider spec into a provider. [*] Provider::ProController: Controller for Refnum 253781, child of 0: unknown, was the Provider itself i am running Multiserver 19.2.0122 on windows server 2016. I am running 8 simultanous backups at the moment, and they seem to run normal my debug loggin preferences are at 3, except with Retrospect API, where it`s zero. Any help would be appreciated

Hi, I'm using a local Minio s3 compatible for storing backups. I have a daily script that recicles the storage member and backups data. The problem is that Retrospect seems that is not deleting data in Minio when recycling and is wasting much disk space. Retospect is latest 19.2. (122) running macOS. Minio is latest, too. Any clue?

First of all, yes, it should show the internal drive as a Source device by default, and any other storage devices that are connected. So something is wrong there. Next, I'd check that you have successfully 'activated' the licence for Retrospect, by checking in preferences, and the licence section. If the licence number is there along with several entries for stuff that you've paid for. If that is the case, that rules out the possibility that the program is in demo mode. [I starting to think there is something wrong with the storage drives...] After that, do a test; setup some favourite folders, and a backup Script, using the favourites as the files/folders to backup, then select a new Media Set to backup to – onto whatever drive you see fit. Of course this is assuming you CAN see your internal drive as a Source to backup. If that works, then there is something wrong with one of your drives, as described by the error message "RefBackujpsetsContainer::CreateBackupset: volRef invalid". If that fails, I suspect there is a drive error either the internal SSD or the drive you're backing up to. You need to check and repair each drive you're using. Then try launching Retrospect again, and see if it recognises your internal SSD drive as a Source, and then backs up the files properly. Let me know what happens. Then we can narrow it down some more.

Just a quick follow-up on this. Not sure if Apple or Retrospect have changed the way external disks are referenced, but each time I reconnect the external disk, I have to re-locate the .rbc file or the backup will fail. If anyone knows how to fix this, I'm all ears!

Thanks for the update. Sorry I think I got the wrong end of the stick there. However, yeh, that is strange being so slow. Seems to be some kind of bottleneck going on with your backup, somewhere. Of course it all depends on how much data is being backed up. For instance my backup is usually around 1-6GB, which takes about 5-10min, backing up my internal SSD to a NAS over 100Gbit network.

@MikeHutch Back 20 years ago, it was 10 Mbit using version 6. And backup times were short. Now I'm running 10Gbit to the Engine and 1 Gbit or better on clients and the time is significantly longer with current high-speed storage and fast networks. Which seems to be going the wrong way, performance-wise. In fact, the clients I'm backing up over the Internet (at best a 200Mbit connection) seem to run faster. In particular, my personal laptop takes 3-4 hours typically. Running a local backup via Carbon Copy Cloner takes around 20 minutes max. While I don't expect Retrospect 19 over a local network connection to match a Thunderbolt 3 SSD, I would not expect it to take 12 times longer. And, with the significant speed improvement that Apple Silicon brings to the table, I would hope to see native software to bring similar performance improvements. But the components are still Intel-only code.

Well there's your problem, 10Mbit network. That is slow. You need a minimum of 100Mbit or more. I'd check your network switch box or router, is probably set at 10Mbit - which is likely the bottleneck of your network. If it is, you need to replace it with a faster unit. BTW, it doesn't matter if your oldest computer has a slower network speed, as the extra bandwidth (100 or 1000Mbit) caters for all speeds.

Looks like you have corrupt files, Retrospect is trying and failing to backup. As you can see via the '(corrupt persistent data)' bit in the log text. To find out what is corrupted, as the log doesn't say specific filenames, I suggest you backup a few folders at a time, as a test backup, until you come across this error, so you can narrow it down. Just look at the log everytime it completes a test backup. Once you've hit on the problem, you'll have to backup 1 folder at a time, you narrow it further, OR, manually check the files in those folders, to see if they open up OK, or not, or just resave them. RHL, I suspect the corrupt file may have gotten corrupted before or after the backup - either way, a file or two are definitely damaged. See above solution for those effected Macs. It's a pain, but that's all I can suggest.

It's rare to have corruption with compressed catalogs - from my 10 years of experience with Retrospect. So I'd say you're pretty safe! Even if the file does go wrong, you can rebuild it no problem - it just takes a bit of time, depending on number of files you've backed up. Regarding the max usage of the drive, just up the amount by 100-200GB in the 'Use at most' box, eg 7353, while leaving room for other files you may want to put on the drive. See if that makes a difference - I believe the app calculates disk space a little differently than straight forward Gigabytes.

Hi There, I always seem to have to recycle my media set when there's around 300-400GB free on the disk. Even if I set the member to use 100%, Retrospect never seems to use that final 300-400GB. Can anyone see what I might be doing wrong? Cheers, Ben

@MikeHutch Awesome, thanks for that Mike - much appreciated. Moving the .rbc file to the top-level of the drive and re-locating it in Retrospect has fixed the issue. Retrospect can see the catalog and a backup ran without issue. Regarding compression, I've always avoided compression as it feels like it introduces a potential point of failure or corruption? Is that fair or is it incredibly rare in 2023? One last thing I've noticed, Retrospect will never use the final 300GB or so of the backup disk. The member is set to use 100% for Retrospect (see attached) but I have to recycle the media set at around 6.6TB instead of 7TB (also attached). Can you see what I'm doing wrong? Cheers, Ben

Thanks for the extensive list of actions you've done, that helps rule out a few things. The basic problem you have, is the catalog file, more over, its location could cause problems (see 1st screen shot). I don't think putting the catalog file in the Retrospect backup folder is a good idea, this an area where Retrospect app has full control over. I'd move the file out of that main folder, and create a new folder on the root of the drive, then move the catalog file into that folder. Obviously you'll have to tell Retrospect its new location. This should solve that issue. The other issue, is that the catalog file may be damaged, in which case you'll have to repair or rebuild it. Also, question: Is the catalog file compressed - see; Media Sets / [catalog selected] / Options? This should reduce the size of it considerably.

Sorry, I just realised that you could try an even simpler solution... Before you do that, I'd try creating a catalog file from the backup disks with your latest version of Retrospect. I think you'll have a good chance of doing that. To do that, go into the Media Sets panel, and click on the Rebuild icon near the top of that window. It will ask for the the backup disks, everyone of them in sequence, and will proceed to build the catalog. Obviously this will take some time. Then you can restore whatever files/folders you want. Without the need to get an old version of Retrospect.

This sounds more like network bandwidth has been throttled down from your highest to the lowest one available. There are a few reasons why this could happen; a) the Macs are using WiFi, not Ethernet; b) the switcher box or router is using a lower bandwidth setting; c) there is heavy traffic on the network, ie backing up too many computers at once; d) the Mac's network settings are not setup to use their full bandwidth, usually 1000BaseT, and it's not full Duplex. I'd look into that first, and see if anything is not right. Then move onto other areas that may affect it.

Have also tried turning-off permissions by ticking 'Ignore ownership' but still no joy. I also tried just adding a new member but see a -1101 error, even with 'Ignore ownership' on. Does anyone know what I'm doing wrong or how to fix?

Retrospect seems to have access to the containing folder, as it can see it from the 'Repair' screen (attached) but if I click 'Next' no member gets added to the list, and nothing happens when I click the repair button. Unless I'm misunderstanding how that screen works. I've also checked that Retrospect has 'Full Disk Access' which it does (see attached). And if I right-click the catalogue and choose 'Open with' MacOS recognises the .rbc file as a Retrospect file. But If I try to open the .rbc file, Retrospect hangs every time (also attached). Does anyone know how to fix? I'm happy to run some Terminal commands if that's easier? Cheers, Ben

Hi There, I've been running this setup for many years but all of a sudden, Retrospect no longer has access to the catalog file. Because I have a laptop with limited space, the catalog lives on an external disk and the .rbc file is 64GB. When I click 'Locate' I can only navigate to the enclosing folder, I can't go into the folder to select the catalog. I've tried running First Aid from Disk Utility and I can obviously access the disk in the Finder but Retrospect can't go into the directory for some reason. Are there permissions I should check or is there some way to give Retrospect access? Any help much appreciated. Cheers, Ben Retrospect 19.2 MacOS 13.5

Where are the Mac files stored? On an internal (fast) SSD? Or an external (slow) mechanical drive? What do you backup? Just the film files? Or all files? Mac OS consists of many thousands of tiny files, which takes (much) longer time than a few large files (if the total amount of bytes is the same). Have you considered disk-to-disk-to-tape backups?