Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 12/28/2019 in all areas

  1. 1 point
    Have you tried the "Options" section of your script? There's also scheduling options there, which only apply to that script (though the defaults reflect the Schedule settings in General Prefs, which might make you think otherwise...) and so would have no impact on manual backups. Set your "Start", "Wrap up" and "Stop" times to suit your working practices and required backup window and you should be good.
  2. 1 point
    I suggest you simply remove the systems from the backup schedule on the weekend, therefore when you boot the systems on Monday morning there won't be a slowdown. You obviously already know how to launch a backup job manually, so just do that.
  3. 1 point
    That's the information I was looking for... So *if* you are only backing up one volume *and* that volume is backing up/verifying successfully *and* you can restore from the backup *and* you get the un-named volume error *and* Retrospect carries on regardless -- I'd just ignore it. If the error is causing other problems, eg killing the script while there are still other machines to process, re-arrange things so the erring machine is the last to be done. If the error is truly killing the system, eg popping a dialog that must be dismissed before continuing, I'd look into script triggers and a GUI-targetted AppleScript to automatically dismiss the dialog so RS can continue. Some things are easier to work round than to fix 😉
  4. 1 point
    As to how the crashing bug report will be treated, read the fifth paragraph in this 2017 post. I have never had ASM, but Tech Support responds to my bug reports; for one bug I was given a test release with enhanced logging—although I didn't get personalized help.
×