Jump to content


The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation on 03/25/2021 in all areas

  1. backy, I was going to make the same suggestion as Lennart_T yesterday afternoon in an additional paragraph in this preceding post—but I had to leave for a dental cleaning appointment. The screenshot at the top of page 176 in the Retrospect Windows 16 User's Guide (I'm referring to that because the Retrospect 17 User's Guides have been subject to the attentions of the StorCentric Slasher—e.g. in the last paragraph of that linked-to-post) shows where to specify the Execution Unit for a Backup script. The screenshot on page 210 shows the same thing for a Transfer Backup Sets script. However you can't set the Execution Unit in a Proactive script that uses a Storage Group as a destination. That's because—as briefly explained in the first three sentences of the last paragraph of this post in another thread—a Storage Group is a magnificent kludge (IMHO) for enabling interleaved backups of different machine-drive Sources using a single Proactive script, rather than forcing the administrator to create a separate Proactive script for each machine Source; the enabling is done by using the multi-threading capability (expressed as Execution Units) of the Retrospect "backup server" Engine. There are two tradeoffs, however. The first is that, when the Knowledge Base article uses the term "volume", it means volume on a particular Source machine. If your 12 Source machines have only one volume each, they would just fit within the limit of 15 Execution Units your "backup server" could—given around 20GB RAM—run simultaneously. But the Proactive script will create a separate Backup Set component of the Storage Group for each machine-volume combination; I've tested this on Retrospect Mac—doing so because the KB article seemed unclear. The second tradeoff is that all the initial Members of a Storage Group's component Backup Sets must fit on a single Destination drive. At least—using Retrospect Windows—the KB article says you can designate an individual one of those component Backup Sets as the Source for a Transfer script. (As the KB article article also says, you can't do that designation using Retrospect Mac—IMHO because the StorCentric acquisition in June 2019 prevented the engineers from fully completing the Retrospect Mac GUI for Storage Groups. But I've tested using a Rule—Retrospect Mac name for a Selector—for restricting Transfer to a component.) Unless you can add additional Members to an individual Backup Set component of a Storage Group (I couldn't test this, because I have to work within the inadequate limits of the Retrospect Mac GUI), you'll have to—after successfully running all your Transfer Backups script(s)—run a Backup script with the Recycle Media Action—specifying the No Files Selector—in order to re-initialize the component Backup Sets of your Storage Group before any initial Member of a component Backup Set exceeds its space on the Storage Group's designated initial Member drive. My personal suggestion is that you abandon the idea of using a Storage Group as a Proactive script Destination, and instead create individual scripts with individual Backup Sets as Destinations for at least each of your "Remote" Sources. It'll be more work to set up, but give you fewer long-run problems.
    2 points
  2. backy, Consider using the Data Compression (in software) option (page 357 of the Retrospect Windows 16 User's Guide) on your Transfer scripts. That'll save tape space. OTOH the option may slow down your Transfer scripts if you don't have a powerful "backup server" machine; the ancient HP DAT 72 tape drive that I use for backing up my (now-deceased) ex-wife's old Digital Audio G4 Mac has a hardware compression capability, but ancient Retrospect Mac 6.1 doesn't support it. I learned about Storage Groups to fully answer other administrators' questions, starting with this March 2019 post in a thread whose OP asked about running multiple Backup jobs to the same Backup Set. I was curious enough to run a couple of experiments on my own home installation, which is how I learned about how Storage Groups really work but also about the limitations of their current Retrospect Mac GUI. If you liked my "amazing" post that much, you could click the "Like" heart icon at its bottom right. The head of Retrospect Tech Support runs a contest every few days; I enjoy competing for "most liked content". Lennart_T's second post in this thread is also pretty helpful, so maybe you should "Like" that post too; competition is good.😁 P.S.: If you're going to give the Backup/Proactive script and the Transfer script for a particular Source the same Execution Unit, I wouldn't use the New Backup Set Backup Action. I haven't used it, but it sounds like a potential complication.
    1 point
  3. That's bad. One workaround would be to schedule both the backup and the transfer to the same execution unit. Then the backup will have to wait for the transfer to finish (or vice versa).
    1 point
  • Create New...