amkassir

I looked around a bit in the Retrospect dashboard and the media set capacities are labeled in GB. Might be less confusing if they were labeled as GiB!

Hello Lennart. Thank you for the reply. I didn't even know about GiB. This being the case, it seems to make sense now. I wonder if most Retrospect users are familiar with GiB. To answer your question, in Disk Utility I see: "Volume capacity : 850,000,003,072"

I've noticed on several occasions when setting up a new Media Set (disk type) that I am unable to get Retrospect to use all available space. For example, I have an 850 GB volume that I'm using for backups, but when I set Retrospect to use "100%" of the free space, it specifies that value to be 791GB. That's a waste of almost 60GB of space Is there a good reason for this to be happening? Is there a way to have Retrospect use all free space? The catalogs are stored on my local startup volume so that's not using up space on the backup destination. Thanks!

Problem solved. I decided to do piecemeal backups of my volume to see if I could determine where the problem file resided. I found that the “invalid handle” error occurred when backing up my user folder, and this time, some of the offending files were listed in the log. It appeared to be more than a thousand files with the same error, all of which resided in the Dropbox folder (~/Library/CloudStorage/Dropbox/). I copied those files to a different volume without any problem and tried to back them up, with no errors. Then I removed Dropbox and all its files from my computer, then reinstalled Dropbox and downloaded all the files again from the Dropbox cloud. After doing this, I was able to do the backup without any “invalid handle errors.” So I guess it was something that went awry in the Dropbox folder. To wit, now the Dropbox folder only contains one item, Dropbox, while previously it contained all other Dropbox folders and files as well. This is strange because all my files are downloaded to my Mac for offline usage, so this might be a symptom of whatever was wrong before.

Unfortunately, the same "invalid handle" error recurred and prevented the backup from completing. The other file not found errors are not concerning. + Recycle backup using MBP SSD Backup to T7 Solo at 2/28/23, 10:40:12 PM (Activity Thread 1) 2/28/23 10:40:12 PM: Finished scanning backup set data files To Backup Set T7 Solo Backup... 2/28/23 10:40:12 PM: Recycle backup: The Backup Set was reset - 2/28/23 10:40:12 PM: Copying MacBook Pro SSD 2/28/23 10:41:00 PM: Found: 1546642 files, 298019 folders, 592.5 GB 2/28/23 10:41:06 PM: Finished matching 2/28/23 10:41:26 PM: Selector "All (no Cache, Retro Catalogs, iOS backups, et al)" was used to select 1,411,955 files out of 1,546,642. No prior backup found for MacBook Pro SSD, skipping Anomaly Detection 2/28/23 10:41:59 PM: Copying: 1374651 files (363 GB) and 37304 hard links *File "/Volumes/MacBook Pro SSD/Users/amkassir/.Trash/.DS_Store": can't read, error -1,101 (file/directory not found) *File "/Volumes/MacBook Pro SSD/Users/amkassir/.Trash/Cocktail16VE.dmg": can't read, error -1,101 (file/directory not found) !Trouble reading files, error -1,100 (invalid handle) 3/1/23 12:03:30 AM: Execution incomplete Remaining: 324,403 files, 237.9 GB No longer present: 2 files, 2.8 MB Completed: 1,050,246 files, 125 GB Performance: 1,591.7 MB/minute Duration: 01:23:18 (00:02:52 idle/loading/preparing)

Hello Lennart. Mac OS Ventura 13.2.1 MacBook Pro 15" 2018 2.9 GHz 6-Core Intel Core i9 Retrospect Version 19.1.0 (219) I permanently deleted the single file in Dropbox trash online (I couldn't find a Dropbox trash folder on my Mac, even when making invisible files/folders visible). Despite not finding the Dropbox .Trash folder, for good measure, I ran the terminal command, sudo rm -r /Users/amkassir/Library/CloudStorage/Dropbox/.Trash/ The command didn't return any error. I'll try another backup and report back.

I'm doing a backup of my boot drive, and encounter errors shown below. One is "MapError: unknown Mac error 11", and the other is "Trouble reading files, error =1,100 (invalid handle)". This last error leads to an incomplete execution. Any thoughts on how to fix this? Thanks. + Recycle backup using MBP SSD Backup to T7 Solo at 2/25/23, 3:37:26 AM (Activity Thread 1) 2/25/23 3:37:26 AM: Finished scanning backup set data files To Backup Set T7 Solo Backup... 2/25/23 3:37:26 AM: Recycle backup: The Backup Set was reset - 2/25/23 3:37:26 AM: Copying MacBook Pro SSD [*] MapError: unknown Mac error 11 *File "/Volumes/MacBook Pro SSD/Users/amkassir/Library/CloudStorage/Dropbox/.Trash/": can't read, error -1,002 (unknown Mac OS error) 2/25/23 3:38:12 AM: Found: 1529865 files, 297893 folders, 592.1 GB 2/25/23 3:38:18 AM: Finished matching 2/25/23 3:38:38 AM: Selector "All (no Cache, Retro Catalogs, iOS backups, et al)" was used to select 1,410,557 files out of 1,529,865. No prior backup found for MacBook Pro SSD, skipping Anomaly Detection 2/25/23 3:39:10 AM: Copying: 1373253 files (363 GB) and 37304 hard links !Trouble reading files, error -1,100 (invalid handle) 2/25/23 4:46:23 AM: Execution incomplete Remaining: 323,817 files, 237.8 GB Completed: 1,049,436 files, 125.2 GB Performance: 1,936.2 MB/minute Duration: 01:08:57 (00:02:43 idle/loading/preparing)

Thank you, Mayoff!

I launched Retrospect today and noticed all the Activities are missing. That's where the history of all my previous backups used to be. I executed a few backups and they appeared in the otherwise empty window. Is there a way to get back my missing history? Not sure why this happened. Thanks. Version 18.2.2 (242)

Thank you for all the replies. I was using a Copy script (not Copy Media Set or Copy Backup) to copy the contents of an actually mounted disk image to another (initially empty) mounted disk image. Based on the posts above, this might be a bug in Retrospect. I haven't yet tried this operation using the newer version of Retrospect. After my post, I tried the same operation with the destination being just a folder on my Mac's internal SSD, rather than residing on a disk image. The same problem occurred. I ended up having to use Carbon Copy Cloner to copy the items.

When copying from one disk image to a second, blank one, the modification date of all folders is changed to the present date and time of the operation. Source disk image: Mac OS extended (journaled), encrypted 256-bit Destination disk image: Mac OS extended (journaled) OR APFS, encrypted 256-bit Any idea why this might be happening? Retrospect 18.0.0 with macOS Big Sur 11.4

Thank you to David and Nigel for your posts. I don't think I mentioned this before, but I'm running Retrospect Desktop, not Professional, and I'm only backing up one machine although I do several different types of backups with different sources and destinations on that machine. Looking at your list of user requirements, I believe CCC allows users to restore obsolete copies of individual files, as long as your source and destination are formatted as APFS volumes and you have snapshots enabled. In this case, CCC does a kind of incremental backup, saving snapshots of the source, as long as destination space permits. You can peek inside of earlier snapshots to pick out individual files for restore. Similarly, you can restore the entire volume from an earlier snapshot in case of a ransomware attack. SuperDuper also uses snapshots to store earlier backups but (a) it's not as easy to access the earlier snapshots and (b) I don't know if you can browse them and pick out individual files like you can with CCC. (I used to use SuperDuper, but because Shirt Pocket Software took a long time to make it compatible with Catalina, I began using CCC and stuck with it because IMHO CCC is superior to SuperDuper. I make these observations in case a reader is considering options for cloning software to use in addition to Retrospect. I have been using Retrospect since 1990 (was that Retrospect 6?) and have never stopped using it, and don't expect to. In fact, I have nearly 20 years of medical records stored in Retrospect's proprietary file backup format, so if it ever comes up, I can show that there is no possibility of being able to illegally modify medical records after the fact. I continue to rely on Retrospect for this perhaps unusual application. Off the top of my head, I'm not aware of any other backup software that employs similarly unmodifiable dated backups. While not truly off-site, I backup to both a local hard drive and a removable SSD, and carry the SSD with me in my briefcase when I leave the office. Thanks again for your posts. I find them illuminating! 👍

David, thank you very much for your post. For some reason, this time Retrospect 17.0.0 didn't notify me of the update when I launched it, so I was happy that your post included the news about the latest update. Using the Check for updates item under the Retrospect menu resulted in an error, informing me that the Retrospect app was running from a location not in the Applications folder, even though that's where it resides, and I launched it directly from that location. So I had to directly download 17.0.1 from the website. After installing it, I chose to check for updates again, and I got this message: Somehow I'm running a version newer than the newest version available? I'm now recommending to anyone wanting an easy restore procedure in Catalina or Mojave to use Carbon Copy Cloner, with my second choice being SuperDuper. How is it that Retrospect costs so much more than these but can't manage a streamlined restore? At least the UG has been updated.

The same problem recurred today after several weeks using these scripts without a hitch. I submitted a support case. Addendum: I received a response from support. Hopefully this will fix it and I'm posting here in case anyone else has a similar problem.

Today I upgraded from Retrospect 16 to 17 and ran one of my daily backup scripts. The amount of data being backed up was a couple GB instead of the expected 20 MB and it completely filled up my small disk image where the backup resides. Inspecting the script, I discovered the source (a folder) had spontaneously been changed to a different source folder, on a different volume. Also, the "favorite" folder that was the usual source was gone from the source list. I had to browse and add it again. So my cautionary tale is to check your scripts before running them after upgrading to 17. This is the first time I've had a problem like this after an upgrade.