Search the Community
Showing results for tags 'tags'.
It looks to me like tag reports still don't work. At least when I create a report that has "Tags Contain...", "Tags begin with" etc., nothing shows up in the report. Can anyone confirm this. I'd like to think that of course they have fixed this by now, but I can't find any evidence that they have. It would be nice to list what items have what tags... right? thanks, - eric
Retrospect 10.0.1 - tag reports don't work. Create and save a report for Tags Contain, Equals whatever - nothing shows up - tags don't reliably show. When you open the Tag tab for a source, often it shows nothing checked, even though the source has a tag, and the scripts using them to select sources are working. See the other bug report with the hint of toggling a dummy tag to make things show up - doesn't always work. Guessing should not be part of a backup routine. - tag list incorrectly shows tag names. My clients have two tags - "24HrBackup" and "AfterHrsBackup". Now all of a sudden, my tag list shows "24HrBackup" twice. Clients that had this tag before show it checked twice, clients that had tag "AfterHrsBackup" show nothing. More guessing. I'm giving up on tags - great idea, but they're hopelessly broken. I'll change everything to directly selecting sources rather than tagging. This will take a while, and time is short because I have to go troubleshoot a client with Retro 8 for windows and the clients aren't getting backed up. Why do I keep thinking paid upgrades are going to fix bugs? Sincerely, a very frustrated long time Retrospect user
I mentioned this issue in a regular post awhile back, but it's annoying enough that I'm generating a bug report. In our setup, whenever we quit and relaunch the Retrospect 9.0.2 console while the engine is running, the console will not display the tags associated with a source volume or favorite folder until either: A source on that client is backed up, or A source on that client is edited, or The client source is refreshed (only works if the client machine is online and available). This issue did not exist for us in Retrospect 8.2. As a workaround, we have created a dummy tag called "Unused tag" so we can edit each source without risking assigning an incorrect tag to it. Checking the box for the dummy tag and then unchecking it a couple of seconds late causes the console to update with the correct tags for that source. If a client source has more than one source volume or favorite folder, we only need to perform this edit operation on one of those sources; the other sources on the same client will then also display correctly. I would consider this a cosmetic issue (albeit a significant one) because it doesn't affect the backups but only what one sees in the console. As with the often-missing information about media set members, it's just another case where the console does not fully populate with data from the engine. This is may be more of an issue for us than for other people. We have long been in the practice of quitting the console whenever it's not actually needed, in order to avoid inadvertently modifying some parameter on the engine. (In Retrospect 8, the console seemed occasionally to generate modifications to rules or scripts on its own, and with either Retrospect 8 or 9, it's all too easy to make an unintended change, due to the lack of confirmation dialogs.) If instead we kept the console running, it would eventually populate with the correct data as the various sources were backed up.
So tags in v.8 were flaky and inconsistent, but v.9 seems to be consistently losing it's settings. I'm starting a new backup set and script. I have a bunch of volumes that I tag as "SAN" and then I set the script to backup the "SAN" volumes. I then run the script, wait about 10 minutes and then quit the Console. When I run the Console again, all the volumes that have not been backed up yet loses it's "SAN" tag. Is this a bug? Anyone found a workaround?