Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by lstone19

  1. And the answer is... It doesn't. But I was careful not to delete anything so it was simple to put the working version of v15 back in place. Will contact Sales on Monday.
  2. If I buy the upgrade license to Retrospect 17, will that work on 16? Currently on Retrospect 15.6. Getting ready to upgrade my first Macintosh to Catalina. Given the reports I've seen about 17.0, I think I would rather run the latest of 16.6 but want to make sure the 17 license will work for 16.6.
  3. David, thanks. OTOH, with further searching, I found in https://www.retrospect.com/en/support/licensing#general "The License Manager will only accept: License codes for an edition of Retrospect that is an upgrade from your current edition" which to me says that it will accept a license from a later version. I might go ahead and try since I think I could then, if needed, run it in Demo mode for 30 days.
  4. I've managed to deal with it (but still don't know why it's happening) by checking the "Ignore client discovery" checkbox on the Options screen of where this system is listed as a Source on the Retrospect Server. Ignore client discovery appears to be a new feature added three years ago in 12.0.0 whose only documentation I can find is a line in the Release Notes: Network New "Ignore client discovery" checkbox for preserving Client's address in certain firewall and NAT environments I have now noticed that on the client, on the Retrospect Client system preference screen, it's sometimes showing an address in the self-assigned range (169.254.x.x) as its address rather than the correct one, even as all networking functions on this client system continue to work normally so no idea where it's getting that self-assigned address. At one point over the weekend, I tried falling the client back to 14.6.0 (I tried to download 14.5.0, the version of the client the other Mac clients are running, from the Retrospect website but it throws an error) but had the same issue. So my speculation in the original post that it's related to the 15.1.0 client appears to be unfounded.
  5. For the last week or so, the Retrospect server keeps changing the address of one of my clients from its assigned internal address ( to an address in the self-assign range ( This seems to be happening daily. This is after years of this client working just fine. It's just this one client (two other Macintosh clients and a Windows client work fine - OTOH, both other Mac clients, despite having pushed the v15 client update to them, say they're still running but that's a separate issue that I see has been brought up in another topic). My fix is to re-add the client via "Add Source Directly ..." (it shows up in the Add box (with "Use multicast") but the Add box stays dim) with the correct IP address which corrects if for awhile (usually long enough to run backups) but then a few hours later goes back to the address). Any ideas? My thought is that since the other clients still claim to be on and aren't having this issue is that it's related to the client but that's just speculation. Retrospect server version: 15.1.2 Client version:
  6. lstone19

    Client Updating Not Working

    Could this be related to OS version? I found with my Macs that the update to 15.x took on a Mac running 10.13.x but did not on two others, one running 10.12.6 and the other 10.9.5 (and never going higher due to machine age and compatibility). Does the updater check version and silently do nothing if the OS version is not high enough?
  7. I don't think I agree. With how I structured things, it used to be one copy copied both the catalogs and the .rdb files. Now it takes two. For the copy to be valid, both the catalog and rdb files must be static throughout - it doesn't matter which is copied first. The real key to integrity (for my use case) is to insure that no other backup activity is occurring - just the copy. But I'm not sure that can be assured in Retrospect unless you set Retrospect to use just one activity thread (I've only recently started allowing multiple activity threads and while I've noticed that it does block some conflicting activities (I think it will not allow a copy from a favorite folder while an enclosing folder is also being copied), I don't know about a copy of a folder while a media set inside the folder is open).
  8. Just upgraded from 14.x to 15.1.1 (102). For years, I've run copy scripts that copy the media sets to external disks used for offsite storage. Starting with 15.x, these scripts will no longer copy the media sets inside the Retrospect folder. If I rename it Retrospect2, it copies (but that breaks backups since that folder must be named Retrospect). I can create other folders called Retrospect down a few level and they copy. But the special Retrospect folder where it puts the media sets won't copy. Specifics: Media sets are on an external drive in a folder called "Retrospect Backups" inside of which are the catalogs (.rbc) and a Retrospect folder with the media sets inside. Copy script uses the entire disk as source with a rule that says include "Folder Mac Path contains /Retrospect Backups/". Destination is a Retrospect "favorite folder" (other scripts copy to other folders on the destination volume). Prior to v15, this worked fine but now it ignores the Retrospect folder found inside Retrospect Backups (ignores here means it neither deletes files that have gone away nor copies any new or updated ones). As a test, I deleted that Retrospect folder on the destination and ran the script and while it recreated the folder, it is empty (source folder contains a few hundred GB). There's other data on the source volume (hence the selection rule) and as mentioned above, other scripts copy other stuff to other folders on the same destination volume so any workaround is complicated. Any ideas here?
  9. I think what you're missing is that this is a "copy", not a "backup". Unless I'm missing something, copy scripts can only have one source unlike backup scripts which can have multiple sources. The way I've set things up, the catalogs and the Retrospect folder containing the .rdb files are in the same higher level folder. So one script to copy the catalogs, another for the .rdb files.
  10. Replying to myself, I found it in the release notes. I guess copying media sets with another Retrospect script was considered a bug. Mac – March 6, 2018 Engine Fixed Full volume backup and copy now exclude backup set content, which can still be backed up or copied using favorite folders (#7212) As it says, they can still be copied using a favorite folder but my testing says the favorite has to be the "Retrospect" folder which has inside it the "Name_of_media_set" folder which in turn has the "1-Name_of_media_set" (or other number as appropriate) folder. So reworked my scripts and it now takes two scripts to do what I used to do in one. Above, I said "ignores the Retrospect folder ... (ignores here means it neither deletes files that have gone away nor copies any new or updated ones)." Now I'm not so sure. In one case, it looks like it left the contents on the destination untouched but in at least two others (with a different script), it had been deleted.
  11. lstone19

    Error -1103 after Windows 10 April Update

    I am also seeing this issue with iCloud on a PC. I run the Retrospect Server on a Macintosh (v15.1.1 (102) with client 15.1.0 (151) on my wife's PC and get -1103 errors on iCloud files (all photos but that's all that's in iCloud). [*] stfiDoBackupOne: error -1103 (write protected) on C:\Users\Maggie\Pictures\iCloud Photos\. [*] stfiDoBackupOne: error -1103 (write protected) on C:\Users\Maggie\Pictures\iCloud Photos\Downloads\. ... Turning off open file backup ("Back up open files" as the option is, at least on the Macintosh version of the server console) gets rid of the -1103 errors but at the expense of -1020 sharing violation warnings, just as I believe was happening with OneDrive.
  12. Upgraded although since recreating the scripts (and I deleted the originals) fixed the issue for me, I have no idea if the upgrade to 15.1.1 did anything.
  13. Upgraded from 14.x to 15.1 this week. Discovered that when one of my old groom scripts ran, the Engine immediately crashed. Recreated them and they ran fine. Only difference was old defaulted to "Use Activity Thread 1" while new defaulted to "Use Any Activity Thread". Changing old script to "Use Any Activity Thread" did not stop crashes. Also annoying was engine crash caused all script changes to be lost. Had to redo the changes, then use the System Preference pane to do an orderly shutdown and restart of the engine. MacOS version 10.13.4
  14. Upgraded to Retrospect 12 over the weekend and all seemed fine at first. But now I've noticed that all my Disk Media Sets have had the total space greatly increased and I can't set it back down to where I need it (to force grooming rather than filling the disk). For instance, one Disk Media Set had its member's "Use At Most" set at 100GB and it now says 157.8GB. I attempted to reset it to 100GB but no change. I'm wondering if this is related to how compressed the media set is. When this backup ran overnight, the second line of the log file was "Adding to 103.1 GB of backup set data, starting at file index 273" but even after backup completion (backed up 5.0 GB per the log), the console shows the used size of the media set to be only 87.3 GB.
  15. Lennart, I have groom scripts and certainly have that in mind as a workaround. But it would be just that - a workaround around a bug.
  16. Bdunagan, no, the individual members (there's just one for each of my Disk Media Sets) have grown as well. Using the set I mentioned above, both the media set listing and the members listing show Space Used: 87.3 GB; Space Free: 70.6 GB; Space Total: 157.8 GB. Before upgrading to V12, the Space Total was 100 GB. And attempting to reset it to 100 GB (by clicking edit for the member) has no effect.
  17. Bdunagan, thanks. I emailed a little after posting and had a response with a download link and new license code a couple of hours later so all is well. And thanks for updating the website language - it's much clearer what to do.
  18. Hmmmm. Only upgraded to 11.x last month so I should qualify for the free upgrade but the site wants me to pay for it. Will call later when I have some free time.
  19. Happens to me too. No pattern to when and why that I can determine. I've never seen it fail to send me a failure email but success emails are hit or miss. I just go into the console each morning to check things out.
  20. lstone19

    Time zone handling wrong in email

    Coming to this late but just upgraded for 8.x to 9.0.2 and saw this problem is still there. It's not new with 9.x as I had it with 8.x. The mail server has nothing to do with the message time. I just did a test by Telnetting to my server's SMTP port and composed a message without a Date: header and the server (Postfix) did not add one. So that Date header is coming from Retrospect. Here's the raw source of the last message from Retrospect to me. Note that SpamAssassin has added to the message's Spam Score for the invalid date (in the future). Return-Path: <retrospect@stonejongleux.com> X-Original-To: larry@stonejongleux.com Delivered-To: larry@stonejongleux.com Received: from localhost (localhost []) by albion.stonejongleux.com (Postfix) with ESMTP id 8BA984582011 for <larry@stonejongleux.com>; Sat, 2 Jun 2012 19:37:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at stonejongleux.com X-Spam-Flag: NO X-Spam-Score: 1.383 X-Spam-Level: * X-Spam-Status: No, score=1.383 required=5 tests=[ALL_TRUSTED=-1, BAYES_50=0.8, INVALID_DATE=1.096, MISSING_MID=0.497, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from albion.stonejongleux.com ([]) by localhost (Server-iMac.local []) (amavisd-new, port 10024) with ESMTP id ASveU5+mTX1J for <larry@stonejongleux.com>; Sat, 2 Jun 2012 19:37:49 -0500 (CDT) Received: from Server-iMac.local (albion.stonejongleux.com []) by albion.stonejongleux.com (Postfix) with SMTP for <larry@stonejongleux.com>; Sat, 2 Jun 2012 19:37:49 -0500 (CDT) Date: Fri, 02 Jun 12 19:37:49 -0600 To: larry@stonejongleux.com From: retrospect@stonejongleux.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: =?utf-8?B?UmV0cm9zcGVjdCBub3RpZmljYXRpb24gZnJvbSBTZXJ2ZXIgaU1hYyAoNi8yLzIwMTIp?= Message-Id: <20120603003749.8BA984582011@albion.stonejongleux.com> Script: A8 Copy Backup Sets to 2400 Client: dimension2400k Date: 6/2/2012 Script "A8 Copy Backup Sets to 2400" completed successfully
  21. I had posted back on 11/30 that I also occasionally see the same problem and my server does has a manually assigned static IP address (always has). But I have not had the issue in the last few restarts.
  22. You're not the only one. I occasionally see this happen too. I generally try to run a small backup right after a reboot to make sure Retrospect is fully there. To the OP: can you share the script you wrote to do the delayed startup?
  23. I was pretty sure but waited until I could run the test again to make sure. Automate > Preview said Normal Backup right up until the scheduled time. It then changed to "Waiting Now: New Media Backup" for a few seconds until the backup actually kicked off.
  24. I had something unexpected happen this morning and am just wondering if that is what I should have expected or is there something else I need to dig into. I have backups scheduled daily for one of my laptop computers. A New Media backup (to a disk file) on Saturday and Normal backups the other six days of the week. I had the computer with me away so before leaving last Wednesday, set Retrospect to skip executions until this morning. Included in the skips was last Saturday's New Media backup. This morning, the scheduled Normal backup fired at the appropriate time but did a New Media backup instead (log even says "New Media Backup"). So my question is, even though the scheduled New Media backup was skipped, does Retrospect somehow mark the Backup Set to be a New Media backup the next time any backup to that Backup Set runs? Retrospect 6.1.230 on Leopard (latest)
  25. I wrote a small test backup script this morning and had the same result - a "skipped" New Media backup causes the next Normal backup to become a New Media backup.