Jump to content

Don Lee

  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Don Lee

  1. Depending on how many machines you are backing up, how important it is to do backups frequently, and other factors, the cost varies, and the importance of upgrading to get *correct* backups varies. I don't know how much upgrading to v12 will cost you (see above), but I can tell you that the list of improvements/fixes between Retro v8 and Retro v12 is very long. If you are backing up Mac OS X newer than 10.8, you are not even getting correct backups. In my opinion, a few hundred dollars for an upgrade is dirt cheap if you value your data and your time. You may have already burned more time keeping v8 running than it's worth. Even if you are evaluating other solutions, just getting today's backups to be correct would be well worth the cost. Buy yourself some time. Just my opinion. No, I don't work for Retrospect. ;->
  2. Don Lee

    Restart Retro Client via Terminal

    FWIW - if you are running 10.8.x or better, and use the built-in screen sharing on Mac OS X, you can log in with another user while your real user is still using the machine. Your remote "login" is invisible to the user at the keyboard. You can log in, do your thing with Retro, and log out. The only thing the user will notice is slightly degraded performance while you're on. You have to have more than one user defined to do this, but all you have to do is use the "other" user's login name and it works. (I set up all my machines with a separate, and mostly unused "admin" user. "admin" owns all the apps, and any "system" files, and the normal users don't have write access. That way the normal user can't mess up the machine without a little extra effort.)
  3. Just out of curiosity - are you really using Retro 8 for Mac server to back up Mac OS X 10.10? Even if you get it to work, there is new metadata in the newer Mac OS that Retro 8 does not know about. I'm surprised that it even runs. I gather the engine is running on Mac OS 10.5.8? Is that the limiting factor on an upgrade to newer Retro?
  4. This may be a glitch I've seen in the console. Sometimes when setting up a new script, it will only offer you a very few backups to restore - as few as one. When this happens, I quit and re-start the console, and the backups appear, as they should. I have found that any time the console is telling me something "odd", I restart the console (just quit and re-launch). 99/100 times, that fixes the problem. Last I saw on this forum, the console still has bugs when dealing with more than one engine at a time, confusing the two engines. Hope this helps.
  5. IMHO - Applescript would be nice, but stability and performance are more important. Applescript is a distant 3rd.
  6. When you do a backup to a media set, the most recent backup (snapshot) of each volume is retained. The older "snaps" are kept on the media set, but you have to "retrieve" them to use them. That means that normally, the only backup that you "see" on a given media set is the most recent one. If what you want is to ony restore the "most recent" backup, this does just what you want. If you want access to the older "snaps", you need to take another step or two. Check out the Media Set panel. Look at the "backups" tab, and the "retrieve…" button in the lower right.
  7. I think I found a bug. If you restore a volume to a client volume, Retro behaves as described above. only a small subset of the data is re-copied to the destination if the restore is repeated. The "permissions" take a while to re-set. If you restore a volume to a local (firewire, direct attach) disk, all of the data is re-copied to the destination volume. Even if I run the same restore script again, with no changes to the destination volume, every file is re-copied to the destination. The setting of permissions still takes a while. I only tried doing this with "restore entire volume" Maybe this is fixed in v12? I'm still running engine 11.5.3 on Mac OS X 10.8.5. Client is 11.5.2 on Mac OS X 10.7
  8. That's a good thing. I've been depending on the ordering, and have not been disappointed. If the scheduling actually ran in alpha order instead of the initial schedule time, that would be sub-optimal. (in my opinion)
  9. I found a problem with the "VM3" machine, and the two other "stuck" volume backups were caused by a single client being stuck. I did not reboot that client, but only killed (sudo kill xxxx) the retroclient process. All is well now. My error.
  10. Yes, you can "move" the server to a new mac. Licensing is tied to the engine, and needs to be entered on install. Moving *just* the engine/application does not work. Also, if you do "move" the server, some things in the config will not translate. For instance, if the catalog files are on a disk that has a different name in the new machine, you'll have to fix that before those scripts/media sets will work. There are KB article(s) about this describing the details. I think this is mostly a misunderstanding. Maybe the support person misinterpreted what you wanted to do.
  11. first off, if you want the permissions restored, and if you are restoring a boot volume, you *must* restore permissions, you have to use "restore entire volume". Yes, I'm aware of that "warning". I think it is misleading, because it doesn't actually erase the volume. The idea that Retro "erases" the target volume is that it will compare the desired result with the files on the disk, and it will delete any files that are not to be restored, add the files that are missing, and leave the ones that are already there alone. That's the moral equivalent of "erasing" the volume first, but that's not what it does. Judging from my experience with this in retro 9+, mostly from the speed of operations, that is what it does - just like Retro 6, which did this really well. I suggest you try it. Restore several gig of data, delete one file, add a spurious file, and then repeat the restore. It should go pretty fast, and delete the spurious file. It should go so fast that it is not credible that it actually deletes and re-restores all the files.
  12. The machine "joy" appears to be stuck because the client is stuck. Screenshot included. It looks like it has been in this state for days. I'll reboot the client, but first - kill "retroclient" process on client. (done) That kills the "preparing for backup", but still leaves the "on/off" switch in the client dimmed so I can't turn it on or off. Back to the console - "refresh" of the client fixed the on/off switch in client control panel. Client is "on" now. Rather than restarting engine, I'll wait until morning and see if it has recovered its sanity.
  13. I saw this again tonight - engine version 11.5.3, running on Mac OS X 10.8.5. I include a screenshot of the console. Note that there are several volumes that need to be backed up days ago, and have not run, yet there are other volumes from the same pro-active backup scripts that HAVE been backed up. Odd. I'm sure that if I restart the engine, this will be OK, and the backups will resume, but it is both frustrating and odd that this happens without any warning. At least one of these has not been backed up since April 2nd, which is a long time. Note that for these 3 volumes that are "stuck", the last activity on them was an error. 2 got "-519 comm failed", and VM3 had the usual assortment of"sharing violations" and "mismatched" data in the compare.
  14. Is this issue addressed by the bugfix in 12.0.1? "Fix for snapshot transfer failing to transfer all necessary BLIB data under certain conditions (#5296)"
  15. Retrospect does most of its work in "differential" mode. If it restores an "entire disk", which you have to do if you want the permissions restored, it will not re-copy data that is already there AND matches the meta data (permissions and others flags) Try it. You'll still have to wait for Retro to restore the permissions, and if you have lots (millions) of files, that can take a long time, but it will do what you want, if I understand what that is. (and yes, restoring a "live" Mac OS X system is not recommended. It could be made to work, in theory, but I would not trust the result, no matter what Retro did.)
  16. I note that this is still happening. I also note that the retroclient.log file appears to be a "circular" file, where new data is written "on top" of existing data to the end, and then started over at the beginning. This saves disk space, but it would still be nice to have useful data in the file rather than repeats of the same message. The reason I noticed this was that I had 4 active IP addresses on this machine, so there were 5 lines of output every 5 seconds, rather than 2. I thought it was a bug related to the "extra" IPs, but that appears not to be the case.
  17. What's up with this? I noticed recently that my /var/log/retroclient.log file is **full** of messages like this: 03 00:09:51: NetCheckNewInterfaces: found new address 03 00:09:56: NetCheckNewInterfaces: found new address 03 00:09:56: NetCheckNewInterfaces: found new address 03 00:10:01: NetCheckNewInterfaces: found new address 03 00:10:01: NetCheckNewInterfaces: found new address 03 00:10:06: NetCheckNewInterfaces: found new address 03 00:10:06: NetCheckNewInterfaces: found new address 03 00:10:11: NetCheckNewInterfaces: found new address 03 00:10:11: NetCheckNewInterfaces: found new address 03 00:10:16: NetCheckNewInterfaces: found new address 03 00:10:16: NetCheckNewInterfaces: found new address 03 00:10:21: NetCheckNewInterfaces: found new address 03 00:10:21: NetCheckNewInterfaces: found new address 03 00:10:26: NetCheckNewInterfaces: found new address 03 00:10:26: NetCheckNewInterfaces: found new address 03 00:10:31: NetCheckNewInterfaces: found new address 03 00:10:31: NetCheckNewInterfaces: found new address 03 00:10:36: NetCheckNewInterfaces: found new address 03 00:10:36: NetCheckNewInterfaces: found new address 03 00:10:41: NetCheckNewInterfaces: found new address 03 00:10:41: NetCheckNewInterfaces: found new address 03 00:10:46: NetCheckNewInterfaces: found new address 03 00:10:46: NetCheckNewInterfaces: found new address 03 00:10:51: NetCheckNewInterfaces: found new address 03 00:10:51: NetCheckNewInterfaces: found new address I *think* this is new behavior, but have not dug back into old, restored log files to verify. Reboot doesn't fix it. It's not a major issue, but does not seem right, and makes the log file useless. I get new messages every 5 seconds, whether the client is "on" or "off". Unlike older clients, it appears that I can't actually KILL the client, as it just gets restarted by launchd. This is the 11.5.2 client running on OSX 10.8.5
  18. When restoring a boot disk, target mode boot is your friend. Boot with the "T" key held on the keyboard. The machine boots, and "looks like" a Firewire disk. You can plug it into another machine, and use it like an external disk.
  19. This is mostly a nit, but would be a plus for those of us who have scripts that have to run in a particular sequence. (like zero the destination, then copy to that destination. Get it in the wrong order, and you get trouble.) What I do is schedule my scripts at times that are different, but not far enough apart, relying on retro to execute them in the order they are requested. For instance, I have scripts: scriptA - 12:01 AM scriptB - 12:02 AM scriptC - 12:03 AM scriptD - 12:04 AM scriptE - 12:05 AM All these scripts specify a particular thread. I rely on this technique to ensure that A, B, C, D, and E are executed in the right order. This works. Each of these scripts can take a while, so at 3 AM, the console shows me little yellow trangles showing the scripts that have not yet run. The only problem is that the little yellow triangles are in the wrong order. It looks like they are in strict reverse order, but I'm not sure. There appears to be the occasional exception. It would be nice if the pending operations would appear in the activities window in the order that they are going to be launched. This is not a major functional issue, but would remove a bit of anxiety from the user ,who might think that the order presented will be the order of execution. BTW - this is retro 11.5.3 on engine and console. Mac os x 10.6 for console and mac os X 10.8 for engine.
  20. Cosmetic problem seen on v12. If you have enough of a list of media sets so that the list in the dashboard allows you to scroll up and down, you may notice that when you scroll down, the bottom edge of the screen leaves a black line across the window, which is erased in a second or two apparently by a refresh. This appears to be a rendering off-by-one error, and only briefly annoying, but is ugly. Console v12 running on mac os X 10.8.5
  21. I ran into a user error during a long sequence of scripts that had to run in the right order. One of the early media set copy operations failed, because the destination was too small (!! My Bad) I wanted to pause everything, recycle the destiniation "manually", restart the copy, and then let the sequence proceed. Unfortunately, I was unable to recycle the destination media set because the "recycle" button was grey-ed out. I looked at other options, but with all scripts paused, I could not do much without messing up my script sequence. I noticed that the destination set that had failed the copy had *no* snapshots listed. I tried retrieving one of the snapshots, and it worked (without un-pausing everything, thankfully) Once the snap retrieval was done, I could recycle the media set - re-run the failed copy, and re-enable the rest of the scripts. I think this is a bug. The "recycle" button should not depend on having a snapshot in the "backups" window. I should be able to recycle a media set that is hopelessly screwed up, or missing, or whatever. I think of it as the "big hammer", and I would expect retro to hammer the set back to the stone age immediately, possibly with a couple of whines if it would be unwise. (like if it would blow away files that look like they are not created by Retro, for instance) As it is, the recycle button is slightly fragile. This is the only time I have had it grey, where I could force it to work. Mostly I have had to do something gross like delete the media set and re-create it. (re-adding to scripts, etc)
  22. The error hints at hardware problem(s). "-1101 error" is a bad sign. It is also important to use the right option when duplicating a volume. Use "restore an entire source volume" and not "restore selected files and folders". The latter does NOT restore permissions as you might expect. (Sorry, but I don't know what it is in the German)
  23. SSL embeds the "name" of the server in the handshake. Using the dotted quad to access the server may well be a problem. The connection may be failing because the handshake fails - because the "name" is not "". That would explain why there are no "connections" to the mail server. If you *really* want to get down and dirty. Fire up tcpdump and filter on the retro server and the SSL port. I'll bet the dotted quad is doing you dirt. (and retro is not presenting the error helpfully enough)
  24. Don Lee

    v12 Update Issue

    If you want to get down and dirty, and manage the individual files of an installation yourself, you can look at the uninstall scripts in the install package, but I recommend relying on just running the scripts. They often scatter files in */Library/*, in prefs, and the occasional hidden file. There is also the odd daemon that has to be killed/started in the right order, with the right mechanism. I'd run the script(s).
  25. My media set "rotations" will happen tomorrow night. The way I have it set up, there are two types of rotations. The ones that work reliably, and the ones that display the bug described above. The scheduled script sequence that (seems to) run reliably looks like this: reset BKSET_last copy BKSET -> BKSET_last (NO recycle options) (check that copy worked manually) (if OK, reset BKSET manually. If not, manually re-do copy) The scheduled script sequence that shows the stunted copies is below. The step that shows the stunted copy is the media set copy where the "recycle source" and/or "recycle destination" option is used. This is all production/customer data, so I have to be careful with experiments. To "try" this, safely, The following script squence is run on the 1st of each month: reset BKSET_last_tmp copy BKSET -> BKSET_last_tmp copy BKSET -> BKSET_last (with dest_recycle option, and source_recycle_on_success option - this is the op that fails) (check for size of BKSET_last - if bad, do manual copy of BKSET_last_tmp -> BKSET_last) I don't think I have ever seen the "recycle source on success" fail. The source is always reset. QUESTION: Is there any debugging that I can turn on in "secret prefs" to help figure out what goes wrong? History tells me that I will see at least one instance of this problem tomorrow night, and it would be a great blessing to get this fixed.