Jump to content

lstone19

Members
  • Content count

    51
  • Joined

  • Last visited

Community Reputation

0 Neutral

About lstone19

  • Rank
    Occasional Forum Poster

Profile Information

  • Gender
    Not Telling
  1. 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.
  2. 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?
  3. For the last week or so, the Retrospect server keeps changing the address of one of my clients from its assigned internal address (192.168.0.70) to an address in the self-assign range (169.254.120.108). 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 14.5.0.146 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 169.254.120.108 address). Any ideas? My thought is that since the other clients still claim to be on 14.5.0.146 and aren't having this issue is that it's related to the 15.1.0.131 client but that's just speculation. Retrospect server version: 15.1.2 Client version: 15.1.0.131
  4. 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).
  5. 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.
  6. Replying to myself, I found it in the release notes. I guess copying media sets with another Retrospect script was considered a bug. Mac 15.0.0.190 – 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.
  7. 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?
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×