Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. (Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here.) roobieroo, If another administrator doesn't immediately come up with an answer, I strongly suggest you file a Support Case for a feature—here's how to do that. The first paragraph below the quote in this April 2021 post in another thread suggests following that up with an e-mail to Werner Walter, Retrospect "Inc"'s Director of Sales Worldwide, describing your problem and giving him the Support Case number. The last paragraph in that same post explains the reasoning behind my e-mail suggestion. The first sentence in that paragraph says that, because StorCentric's previous products—before they bought Retrospect Inc.—have been NASes including Drobo, StorCentric has required "Retrospect developers—with help from other StorCentric developers—to produce a version of the 'backup server' program that runs on a beefed-up Drobo [NAS] device (and probably on other Linux-based NASes)." The latest I hear is that that "backup server" version may miss the Retrospect 18.0 release, which is expected by the end of June 2021. However IMHO StorCentric top management won't be pleased to hear that the "backup server" for Retrospect Mac 16 (unless you've recently upgraded to Retrospect Mac 17—whose cumulative Release Notes list fixes for bugs #8597 and #8600 that possibly might fix your problem) doesn't back up "Applications/installers on the NAS that generate this error message or if a user copied items to the NAS that would normally require full disk access such as their Library folder." Politics.😎
  3. Yesterday
  4. I have the same issue even with those items checked to allow full disk access. Most of the data on the Synology backs up just fine. It seems to be only Applications/installers on the NAS that generate this error message or if a user copied items to the NAS that would normally require full disk access such as their Library folder. It's helpful to have commonly used installers on the NAS so people don't have to search for and download them but it's also a pain since it generates tons of error messages in the log during every backup. If you find a solution to this I'd love to know what you did.
  5. Last week
  6. Earlier
  7. DavidHertzberg

    Cloud Backup Strategy

    dvenardos, My re-reading of your OP and reading of your second post made me realize that you started this thread for the sole purpose of showing your boss: "Look, I told you Retrospect couldn't do the off-site backup the way we want to do it—and here's proof that Retrospect users (not only their Tech Support) admit that." That makes me angry enough that I'm going to spend a few more minutes casting further doubt on the way you want to do off-site backup.😡 First, here's a 2018 thread from this very Forum that discusses blm14's desire to use an Amazon VTL. Starting with the post below blm14's OP, I and Nigel Smith pretty definitively shot that down as a bad idea. The only thing I have to add to that is Retrospect as of 2016 supports 28 Virtual Tape Libraries with either iSCSI or Fibre Channel interfaces. You insist on using the only two VTLs that interface over Ethernet; I find it difficult to believe that in your new colocation facility you can't connect a VTL except over Ethernet. Besides, as the second paragraph in my first post in that linked-to thread says, "what blm14 would be getting for that cost is 'low-latency access to data through transparent local caching'." You don't need local caching; you're already doing that with the Ola Hallengren SQL Server Maintenance Solution. That's probably why Retrospect doesn't support Ethernet VTLs; one can do local caching using Retrospect scripts. IMHO, for you VTLs are just another gimmick for giving non-cloud-destination backup applications cloud destinations. Second, you admit that the cloud solution you want isn't going to have a monthly cost appreciably less than sending tapes to Iron Mountain. Pardon me for boring everyone else on these Forums with a repeat of how I do off-site backup in my itty-bitty home installation: Every Saturday morning I do a Recycle backup of all my drives to a rotated-in portable storage device. Then, early every other morning of the week, I do an incremental backup to that same portable storage device. Every Friday mid-morning I carry the current-week portable storage device off-site to my bank branch two short blocks away and put it in my US$90/year safety deposit box, after removing the portable storage device I put there last Friday. Since my bank branch isn't open 24/7/365 for immediate retrieval, I actually don't immediately re-use the portable storage device I retrieved—but instead store it just inside my apartment door for a week before re-using it. Thus my 3 (only 2 needed given 24/7/365 retrieval) weekly-rotated backup sets are designated Red, White, and Blue. And here's tape news; I now actually use pairs of portable storage devices; the device for my new computers is now a portable HDD, but the device for my late ex-wife's 2001 G4 Mac is a DAT tape cartridge (because two years ago Retrospect Inc. eliminated the ability to backup Macs with really old versions of macOS, so I run an old version of Retrospect on that old machine to backup using the DAT tape drive I used for years). Last week I temporarily took home everything else stored in my bank safety deposit box, so I can tell you immediately (after measuring a folded document that was also stored in my box) that my US$90/year safety deposit box is just wide enough to hold an LTO cartridge—and long enough and high enough to hold a dozen stacked. Do you really mean to tell us that, if you sent a pogue to your colocation facility every three months carrying an LTO-8 tape drive and several LTO-8 cartridges, the other people at that facility would not permit him/her to plug in the tape drive and sit there changing cartridges until your every-three-month "archiving" job is finished—after which he/she would carry the newly-used cartridges to a bank safety deposit box? 🙄 I decided years ago that if Kim Jong Un H-bombed New York City my little retirement business as well as my personal affairs would be ended, so I don't store my portable storage backup devices at Iron Mountain. If your organization needs to do off-site backup that can survive a nuclear attack, may The Auditor bless it. 🤣 P.S.: Mellowing slightly to consider how to do what you want with Retrospect: If each of your SQL Server backups won't exceed 25TB, you should back them up to the cloud using four 3-months-rotated destination backup sets. You'd create a separate schedule for each destination backup set by clicking the Schedule button, scheduling it at 3-month intervals per pages 232–234 of the Retrospect Windows 16 UG. For each of these 4 schedules you'd designate the destination backup set per the To: pop-up shown at the right bottom of the second screenshot on page 233; of course you'd have to have pre-defined all 4 destination backup sets per page 177. You'd also specify Recycle Backup in the Action: pop-up to the left of the To: pop-up, so that each backup set would be reused once a year. So long as you use cloud destination backup sets this isn't going to decrease your cost—but it would avoid the danger Retrospect Tech Support warned you about. You could greatly reduce costs by instead using 4 tape destination backup sets, per the third paragraph of this post, which wouldn't limit the size of each destination backup set to 25TB. AFAICT your RClone solution would run into the same 100TB total limitation at the remote site, unless the remote site isn't subject to the same limitation as cloud providers.
  8. dvenardos

    Cloud Backup Strategy

    Thanks for the response David! I am using the latest version of Retrospect for Windows. To clarify what is happening (for any readers of this post), native compressed SQL Server backups are going to a network file share via the Ola Hallengren SQL Server Maintenance Solution: https://ola.hallengren.com/sql-server-backup.html. The backups are retained for 3 months. Previously we have been doing tape backups via an old version of Symantec Backup Exec and System Center DPM, we are retiring those systems in favor of Retrospect due to numerous issues. However, we are moving to a colocation facility and tape backups are no longer viable. Our current monthly Iron Mountain costs are in the $500 - $700 month range. Looking at the options, Retrospect is not really viable as a cloud tape replacement at this point. It doesn't support AWS tape gateway or StarWind VTL. For this use case I am going to use RClone with the copy command (https://rclone.org/) on an encrypted remote site. This will achieve the objective which is to retain the SQL backups for at least one year. We are going to BackBlaze B2 and I can setup a lifecycle policy to delete old backups. The monthly cost is comparable to Iron Mountain and retrieval fees are also inline with Iron Mountain tape requests.
  9. DavidHertzberg

    Cloud Backup Strategy

    (Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here.) dvenardos, I assume (you didn't say) you intend to use or are using Retrospect Windows, and that it will be the latest version (you didn't say)—rather than some ancient version you inherited from your predecessor. However the page references I may give you are to the Retrospect Windows 16 and Mac 16 User's Guides, because an employee I call the StorCentric Slasher has robotically deleted screenshots and explanatory paragraphs from the version 17 UGs. Don't worry, the features I may talk about in this thread haven't changed in years, and Retrospect Inc.'s Product Management refused to update anything besides the "What's New" chapters of the UGs from 2015–2019. I'll further assume that your objectives in "archiving"—in your sense of the term rather than Retrospect's— this data offsite is either [1] to guard against a disaster—such as flooding—happening to your server room or [2] to enable not-so-rapid recovery of old transactions you must legally retain without tying up disk space in your server room. I agree with Retrospect Tech Support that both these reasons argue against your using Cloud backup sets. As to objective [1], IIRC most cloud providers effectively limit a customer's downloads to about 20TB per day. So it would take 1.5 days to do disaster recovery from even one of your proposed 30TB Cloud backup sets. I don't think your upper management would be happy about that kind of delay.🙄 Amazon Infrequent Access will cost your organization US$1250/month for storing 100TB, although you may be able to cut that price to US$400/month using Archive Access Tier or with cheaper suppliers such as Backblaze B2. IMHO you'd be better off doing your "archiving" to LTO tapes, at an initial cost of around US$3700 for a tape drive plus 8 LTO-8 tapes (assuming you can't do further compression). LTO tape cartridges measure 102.0 × 105.4 × 21.5 mm; if your organization can't find an off-site location to securely store a dozen of those for physical access within 3 days, it has other problems.🤣 As to objective [2], if I understand you correctly, your Retrospect Cloud backup sets would only contain one file for each 3 months of backups of a SQL Instance. So you'd have to say "the transactions we want must have been backed up from this SQL Instance sometime in that 3-month period", download and restore with Retrospect the entire SQL Instance, and then use SQL Server to to pick out in the SQL Instance the desired transactions. That doesn't sound like a speedy process. 🤣 However if you were backing up at the transaction level—which I understand is possible with some non-free SQL Server backup software—then Retrospect backup sets could be used in a more-precise manner. P.S.: Based on hurried first reading of your OP, I thought there'd be a question about Retrospect doing backups at 3-month intervals. So—before reading the OP carefully—I'd already looked it up on pages 232–233 of the Retrospect Windows 16 UG and pages 133–134 of the Retrospect Mac 16 UG (ver. 16 because—as I expected—the StorCentric Slasher has deleted the associated screenshots in the ver. 17 UGs). I also did an experiment on my Mac 16 "backup server"; the dialog label line starting with "every" does indeed change to "month(s)" when the "repeat" line above has "monthly" in the pop-up.
  10. (Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here.) SHAB, I did get an answer from the Worldwide Head of Retrospect Sales, the following day—16 April 2021. It was IMHO the first thing you should do is to file a Support Case for a feature request. Here's how to do that. I can't do it myself because [1] I use Retrospect Mac—not Retrospect Windows and [2] I don't use Docker in my simple home installation. My personal experience is that Retrospect Support will ask the person who files a Support Case to be a beta tester for the requested feature or bug fix. The second thing you should do is to e-mail Werner Walter the number of your Support Case—which you should write down when you submit it. I'm sorry to subject you to the deficiencies of Retrospect "Inc."'s Support Case software. They've rented the software starting years ago from another company (who also rented it to the Taiwanese hardware company ATEN, which made my 5-year-old KVM switch), and—as I've noted in the linked-to post—it's somewhat primitive. It's designed so that—for Retrospect customers rather than employees (such as Werner)—only the customer who submits a Support Case can read it. Be aware that what's going on behind the scenes—see my disclaimer above—focuses on the management of StorCentric (which "merged" Retrospect Inc. into itself on 25 June 2019) requiring Retrospect developers—with help from other StorCentric developers—to produce a version of the "backup server" program that runs on a beefed-up Drobo device (and probably on other Linux-based NASes). I dare to say this much on these Forums only because Mihir Shah, the CEO of StorCentric, publicly announced in 2019 that he wants to do it. Since NASes don't have their own monitors and keyboards and mice, this means that non-Management Administration Console programs must be developed that control the "backup server" from another machine on the same LAN/WAN. Retrospect Mac has had such an Administration Console since 2009. However—for reasons explained in this section of the old version of the Wikipedia article—Retrospect Inc. had to leave the Retrospect Windows "backup server" with a multi-threaded implementation of the same built-in GUI it's had since the early 1990s. So Retrospect "Inc." has now brought in a GUI development expert, but from what I hear there are a lot of meetings going on—presumably about what the new GUI should look like etc.. That's why the release of Retrospect 18.0 has been delayed far beyond the early-March date customary for x.0 releases of new Retrospect versions. I've been told that the release of Retrospect 18.0 is expected before the end of June 2021.
  11. I do find it a bit disturbing that you have not got an answer yet, not even a "we will look in to it and get back to you". Or even a "Thank you, great input!". It feels a bit like they have not got a clue what the information we feed them with say. (Trying to interpret the silence). Well, time will tell if the penny falls and they realize the potential of backing up docker containers. Or just having a client that works for the rest of the filesystem even if there is docker installed on the system and you do -not- wanna backup the containers. I'm staying tuned for any change!
  12. I am trying to figure out how to backup a Window's network file share to cloud. The network file share is a target for native SQL Server compressed backups handled outside of Retrospect. Example file share path is: \\fileserverX\SQLBackup. The file share contains around 30 TB of backups which represents 3 months of compressed SQL Server backups. The subfolder structure in the file share is: \\fileserverX\SQLBackup\SQLInstanceX. Folders are created inside of SQLBackup for every SQL instance that is being backed up. The backups are automatically pruned after 3 months. I need to archive these native SQL Server backups to cloud and retain them for a minimum of one year, but potentially two. The maximum cloud backup set size is 100 TB and Retrospect supports strongly discourages using a backup set size that large. All I really need to do is encrypt the backups and copy them to cloud storage, they won't ever change once created. I can't really use multiple cloud backup sets because I can't easily subdivide the network share into smaller subfolders. Any ideas on a strategy for archiving this data to cloud?
  13. Great work David! I hope there was some error along the way to the developers, keep this post updated. For further reference on Bacula you can read this: Bacula and Docker Now, either you wanna backup anything about the docker or just a simple file on the Linux client Retrospect should be able to handle the client and the filesystem. One could expect to be able to take backup of your /home or what ever you fancy while Docker is installed. I do wonder if the retroclient stops working if you install docker on a windows server? If anyone reading this knows, please drop a reply! The retroclient should not freak out and die because Docker is installed on your system(linux, mac or windows), right? Regards, Pontus
  14. SHAB, Yesterday I phoned the Worldwide Head of Retrospect Sales, and left a message asking whether the soon-forthcoming Retrospect 18.x would handle Docker containers. He phoned back (because they've got several people out sick and he was in meetings) while I was out to dinner , and left a message that is a bit muddy on my answering machine. When I listened to it again tonight, I understood him to be saying that Retrospect "Inc." has no plans to handle Docker in Retrospect 18.x. However his message indicates that he believes Docker is a Linux distribution, and I shudder to think about how he re-phrased my question when talking to the engineers. 🙄 I'm merely an ancient home user of Retrospect Mac (although one of my "clients" in 2002–2004 was a Windows 95 machine forced on me for Work From Home by my bosses' boss). The only time I've ever encountered a VM was briefly as a remote user in 1969 of what was later to become IBM's mainframe VM/370, but I do read enough Ars Technica posts to be somewhat aware of what Docker is and its current importance. I'll write him an e-mail tomorrow, containing links to that Wikipedia article as well as to this thread—and stressing that Bacula will handle Docker containers. Salespeople worry about competitor's capabilities, so that should perk up his ears. 🤣 P.S.: E-mail sent 21:37 on 15 April 2021. In the first paragraph it also links to the Ars Technica front-page article saying Docker now runs natively on the Apple Silicon M1 chip, as requested by many developers. In the second paragraph it also links to a YouTube video on Bacula Enterprise Principles, a Web page showing Bacula's "backup server" only runs on Linux or FreeBSD or Solaris, and the Web page on Bacula and Docker you linked to below. I then said "Bacula—rather than just Synology’s Hyperbackup or OWC's maybe-back-from-the-dead BRU—looks like the competition StorCentric will run into for the Retrospect 18.x 'backup server' running on Linux [publicly predicted by StorCentric management]." How's that for motivating Product Management? 😎
  15. Anyone knows where to read about Linux fix #8985 ? Been trying to find it but finding nothing...
  16. Thanks for your answer David! Well, I did read that but thought it was "history". I initially failed to mention that the server side run on windows and is running the latest version of Retrospect Server. So, from whatever fix they made (#8985) it was not for servers running with docker installed 😞 I guess we will have to try some other backup solution for those servers running docker... We "only" have two so far but the plan was to expand that. Would have been nice if the Retrospect team could solve this since we have read about other backups that supports it and even supports backing up the containers. One example is Bacula. But we would prefer not having one more backup system running. I will let this question hang out a bit more and see if there is any more info to get. Regards, Pontus
  17. SHAB, Unfortunately this post in a January 2020 Forums thread says However that was for Retrospect Mac 16.6. You might consider upgrading your "backup server" to the latest 17.5.2 release, if you haven't already done so. For that release, the cumulative Release Notes for Retrospect Windows include
  18. Hello! We have been running Retrospect for years and seldom had any major problems, until today! We have been backing up a lot of Linux clients, mainly Ubuntu. Recently there is two new clients to backup that we just don't get to work. What is different from all other clients is that they have docker installed. They both run Ubuntu 20 fully patched and have the retrospect client Version 17.0.1.132. When connecting to them and checking volumes from the server it starts to show a lot of them, some with an icon of a pen with line across it, then after displaying all they drop off until none left. And so it goes on... Picture attached below. Now, what is wrong with the client? Why is it bananas just because we have docker installed on the client that is to be backed up? Any hints would be much appreciated! /Pontus
  19. cgtyoder

    Disaster Recovery doesn't support high DPI screens

    Already been talking to support. They walked me thru the garbled screens. This is actually for Windows on a MacBook Pro (a "Boot camp" partition). Turns out Dantz doesn't support Disaster Recovery on Apple hardware - too bad I didn't know about that ahead of time. Looks like I'll be reformatting & reinstalling everything manually - what a PITA. Looks like also I'll be changing what backup software I use...
  20. DavidHertzberg

    Disaster Recovery doesn't support high DPI screens

    IMHO cgtyoder—because he's definitely got a license for Retrospect Windows 17—should create a Support Case at https://www.retrospect.com/en/rscustomers/sign_in?locale=en . If he isn't already signed-up he should click that link to do so. He should be aware that, if his problem statement runs much over 2000 characters (16 lines of a 9-inch-wide inner window), it will spill over into an Additional Note. He should also be aware that Retrospect "Inc"'s highly-advanced Support Case system doesn't allow linking or underlining; I use before-and-after underline characters, and I paste-in links with a space afterward to facilitate copying into a browser link window. Having done that, cgtyoder should put the Support Case number into new a post in this thread. x509 can then create another Support Case, with a Problem Statement mention of cgtyoder's Support Case number. That will get around the wonderful feature that limits access of a Support Case to the administrator who submitted it. Be aware that these problems may turn out to be a result of limitations in Microsoft's WinPE underpinnings for Disaster Recovery.
  21. I have the opposite problem. A low DPI laptop screen. A secondary monitor doesn't work. (Lenovo T series)
  22. mbennett

    Disaster Recovery doesn't support high DPI screens

    The only possible idea I can offer is that if you can plug an external, lower resolution monitor into your laptop, and it it lights up (both very big "ifs" I realize) that may give you the ability to view a screen. I assume the second monitor is made accessible in the BIOS, so it's something to try.
  23. I am in the process of attempting to perform a disaster recovery (latest and greatest R 17.5.2.103) on my laptop with a high DPI screen, and when I boot from the WinPE disk, the text is garbled or only partially displayed - it looks like the screen is corrupted. I added in my laptop's drivers before creating the recovery disk, but that didn't help. There's really no excuse for lack of high DPI screen support in 2021 - any idea for a workaround so I can get my PC back up and running?
  24. backy, After some more belated thought and one little experiment, I'd like to revise my recommendation in the last paragraph of this up-thread post. If you want to use a Storage Group defined on a Retrospect Windows "backup server" as a Destination, you may be able to get away with it—but I'd advise against it. My belated thought was that you could define a Grooming policy for the Storage Group. My experiment showed I can do this even on a Retrospect Mac 16 "backup server". Presumably the Grooming policy is applied to each component Backup Set as it is automatically created—when a new machine-volume is added as a Source for a script whose destination is the Storage Group, but I can't confirm this because of the so-far-incomplete Storage Group GUI in Retrospect Mac. Also presumably in Retrospect Windows you could modify the Grooming policy and the initial Member size for a particular component Backup Set, but again I can't confirm this. Ability to do those modifications depends on the capability of using the Retrospect Windows GUI to directly access a component Backup Set; there's currently no such capability in Retrospect Mac's GUI. The combination of these two capabilities—if they exist in Retrospect Windows—would allow you to tailor the maximum initial Member size for a particular component Backup Set. This—done carefully—would enable you to ensure that the sum of all components' initial Member sizes would never actually exceed the size of the Storage Set's defined Destination disk. Therefore, if you ran Transfer scripts frequently enough, you could make sure that all files from components had been Transferred to tape before they were groomed out of existence. So you wouldn't have to run any Recycle scripts having as a Destination the Storage Group; you could rely on the components' Grooming policies. If you can add additional Members to a particular component Backup Set, that would provide an additional safety factor. I can't do this either, again because the so-far-incomplete Retrospect Mac Storage Group GUI won't let me directly access a Storage Group's component Media Sets. Of course your Transfer scripts wouldn't be copying files simultaneously backed up by your Proactive scripts (because you couldn't make them use one Execution Unit)—pending enhancement per my Support Case #54601 (case# in P.P.S.). And it'd take substantial effort for you to explain this strategy to another employee of your company. Undoubtedly my recommendation in that up-thread post that you not use a Storage Group is still the wise choice.
  25. What Lennart_T says may "always" be true nowadays—especially for LTO "tape stations", but it wasn't true in the past. IIRC my first DAT drive, from DAT Technologies, did not have hardware compression—which I could have used because I was at one point backing up 4 machines in my and my then-wife's home installation. I was creating at least 2 DAT tapes from my 7-hour Saturday Recycle runs, but I couldn't use software compression because my "backup server" machine was slow. I had hopes when I got the HP StorageWorks DAT72 drive, but it turned out Retrospect Mac 6.1 didn't support its hardware compression feature. backy, make sure for your Transfer scripts that you don't click the More Choices button shown in the dialog on page 213 of the Retrospect Windows 16 User's Guide. Those lead to the options shown on pages 360–361, but you want those options to default to Match source volumes to Catalog File and Don't add duplicates to Backup Set. That will make sure newly-backed-up-to-disk files are copied to tape once—and only once—so long as their contents don't change, allowing emergency retrieval despite later grooming of your disk Backup Sets.
  26. LOL, that's what I was just wondering! We're all in sync here...
  27. Hi David. You raise a good point about Compression and the speed cost. Our LTO-6 drive has hardware compression Retrospect supports. Our server is circa 2012, 2.4Ghz quad-core Xeon, with 16GB RAM. We have two to three people using Remote Desktop into their user accounts all day. As I understand it, Retrospect automatically uses hardware compression if it exists. I think I'll uncheck Compression while backing up to the hard drive sets to keep things backing up quickly and not hammering the server, and then let the hardware compression work when we transfer to tape...does that make sense? I actually don't see an option to turn off hardware compression anyway, but I could have just missed it.
  28. I think tape stations always have hardware compression. I don't even think you can turn it off (in Retrospect). So trying to turn on software compression is useless, I'm afraid.
  29. 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. Load more activity
×