Jump to content

PaulMikeC

Members
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About PaulMikeC

  • Rank
    Occasional forum poster

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. PaulMikeC

    Event Handlers

    Hi Nigel, That '/dev/console' idiom seemed to come closest to what the tilde ('~') char in the original sample script was meant to do. As you pointed out though, it could end up varying too much, depending on login patterns. That's why, in the second parenthetical '{EDIT:- …}' in my post of 25th May, I too had suggested that it might be easier to simply hard-code the log pathname. {In fact, I myself later switched to doing just that, so my log file is always on the main user's Desktop. I'm now thinking about incorporating some kind of automatic log rotation (perhaps similar to what the OS does for system logs) with zipping, etc.} I do also hope that you got your Slack integration to work! 🙂 —Paul
  2. PaulMikeC

    Event Handlers

    Hi again, David, per your advice, I've submitted a Support Case requesting that at least the sample event-handler Bash script be adjusted to address this issue. I outlined a handful of possible approaches, ranging from merely adding a suitable comment to making various small code changes (including one based on my preceding post). BTW, I've also managed to implement the VMs pause / resume functionality in Retrospect Event Handling that I originally wanted, by modifying the Bash script's 'StartScript' & 'EndScript' functions to detect my VMs Backup Script by name, and then respectively call my existing lower-level VBox VMs pause & resume shell-scripts (that are also being invoked by my similar "flighting" scripts in CCC). So, I'm fairly happy for now. 🙂 --Paul
  3. PaulMikeC

    Event Handlers

    Hi David, Yes, that thought had actually occured to me too, so during my experiments I did in fact also try removing the name-extension from the event-handler script file, and even in desperation changing the filename to all-lowercase, again to no avail. However, I have in fact solved the issue, and it turned out to be a classic case of "User Error". 😉 Actually, the event-handler script does work fine when named 'RetroEventHandler.sh', and its owner can be left untouched (i.e., it does not have to be changed to 'root'). As a seasoned developer, I’m rather embarassed to have to admit that I was simply looking in the wrong place for the generated log file. I just plain forgot that since the event-handler script is being run as 'root' by the Retrospect Engine, a tilde ('~') character at the start of a pathname (such as the '~/Desktop/eventhandler_log.txt' file defined in the sample script's 'log' function) would of course resolve at run-time to the home directory of the 'root' user , rather than the logged-in user. So, when I looked instead in my boot disk's '/var/root/Desktop/' directory, there indeed was the expected log file, faithfully recording events all along! {EDIT:- My 'root' account happened to have a Desktop folder, since long ago I used to enable the 'root' user (via Directory Utility) and occasionally log in as 'root' to perform some system tasks. On a typical system with the 'root' user disabled, there might be no such 'root' Desktop folder, and so the log file would not actually get created.} For convenience, I’ve now changed the sample script so that the log file is written instead to the logged-in user's Desktop, by first obtaining that user's name via an idiom that I borrowed from a CCC sample pre-flight script, i.e. (in modern Bash syntax): me="$(stat -f '%Su' /dev/console)" and then inserting that 'me' variable's value to form the new log pathname: "/Users/$me/Desktop/eventhandler_log.txt". {EDIT:- Although, it might be easier to just hard-code the log pathname, e.g.: if the same user is always logged-in on the backup server; or, to ensure the log gets written to a fixed location.} Anyway, so sorry to have wasted everyone's time. At the moment, all is well with my tests of the sample event-handler script. Now to tackle implementing the VMs pause / resume functionality that I mentioned earlier. --Paul
  4. PaulMikeC

    Event Handlers

    I have this issue too. My Retrospect "backup server" is also my everyday workhorse computer, a Mac Pro (Mid 2012) tower running macOS 10.13.6 'High Sierra'. The backups cover various local source volumes, including several internal, external & (occasionally) network drives, with the destination being a local 5-bay external enclosure, and are scheduled for overnight runs. I recently upgraded my Retrospect Mac Desktop Edition to 15.6.1 (from 13.5, and before that, 9.0, 8.x & 6.x), and was pleasantly surprised to see that this venerable Event Handling feature had been re-introduced in version 14. Some more background info:- For extra insurance & convenience, I also use other services & utilities to make additional types of backups, such as Dropbox online sync, and emergency clone. For instance, I make a nightly bootable clone of just my tower's boot disk via Carbon Copy Cloner (CCC) v5.1. That work is split into two CCC tasks: the first one clones everything except my VirtualBox virtual machines (VMs)' storage files; and, the second one runs much later and clones only those VMs-storage files. That second task uses pre-flight and post-flight scripts to, respectively, pause and resume any running VBox VMs before and after the cloning. I would like to do the latter's equivalent in Retrospect, via event handling. At the moment, I’ve simply copied as-is (from the 'Sample SH' subfolder in the Script Hooks download) the 'RetroEventHandler.sh' sample shell-script, into the boot disk's '/Library/Application Support/Retrospect/' folder. Unfortunately however, it seems I cannot get the Retrospect Engine to invoke the shell-script at all. I've tried various approaches, such as changing the file's ownership to 'root', restarting the Engine, and rebooting the tower, but all to no avail. (OTOH, for me too, the shell-script runs fine when manually executed in Terminal, either with appropriate test arguments or via the 'harness.sh' sample wrapper shell-script.) Any assistance would be welcome.
  5. There are a few older threads that discuss Rule syntax for OS X. One such thread is 'What is correct Mac path format for exclusions?', which offers some working examples of 'Is Like' (among other aspects); it is available at: http://forums.retrospect.com/index.php?/topic/27819-what-is-correct-mac-path-format-for-exclusions/ --Paul
  6. Hi all, Historically, it's been useful to have the ability to add the occasional custom entries to the special software-compression filter, to accommodate newer/other kinds of compressed files such as iTunes Store media ('.M4P', '.M4V', etc.). Now that this special rule is hidden in the Retrospect 8.2 GUI, is there any alternative way to edit it? --Paul
  7. Just throwing out another possibility... From my own experience, when software-compression is enabled, and the built-in '~Compression Filter' Selector isn't already configured to ignore certain file-types, Retrospect can often end up trying to recompress already-compressed data (e.g., '.m4a', '.m4p' or 'm4v' media files from the iTunes Store). At best, this could consume a great deal of extra time for little if any size-reduction, and at worst it could also even slightly increase the size of the backup. If this fits your situation, you could just edit that built-in '~Compression Filter' Selector (first saving a backup copy of your '/Library/Preferences/Retrospect/Retro.Config (m.n)' file just in case), to add the additional file-types and/or filename-extensions that you wish to exclude from recompression. Good luck, --Paul
×