Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 07/04/2019 in all areas

  1. 1 point
    Nigel Smith, I finally figured out the explanation for the confusing Copy Backup popup option explanation in the Retrospect Mac 17 User's Guide (you're citing that version, though Joriz runs 16.6) page 121. We must detour to page 177 of the Retrospect Windows 17 UG, where it is written of Transfer Snapshot—the equivalent operation with the same options described in a slightly-different sequence: So why did they butcher this explanation for Retrospect Mac 8 and thereafter? The reason is that the term "snapshot" was abolished in the Retrospect Mac GUI because by 2008 the term had acquired a standard CS meaning, eventually even at Apple. Starting in 1990 the Mac UG (p. 264) had defined it: The term "active Snapshot" is not defined even in the Windows UG; it means a Snapshot that the "backup server" has given the status "active" by keeping it in a source Media Set's Catalog. As we see from Eppinizer's first paragraph quoted here up-thread, it is the single latest Snapshot if the source Media Set has grooming disabled—but is the "Groom to keep this number of backups" number of latest-going-backward-chronologically Snapshots otherwise. So that's why the choices in the Copy Backup popup have the word "backups" as plural. I'll create a documentation Support Case asking that the august Documentation Committee put Eppinizer's definition of "active" backups/Snapshots into the UGs. But "a backup that is kept in the Catalog" sounds silly.
  2. 1 point
    Joriz, First read pages 14-15 of the Retrospect Mac 13 User's Guide. That's why grooming isn't doing anything to reduce the size of your disk Media Sets. If even one source file backed up to an RDB file is still current, then performance-optimized grooming won't delete the RDB file. You should be using storage-optimized grooming unless your disk Media Sets are in the cloud—which you say they aren't. (It seems the term "performance-optimized" can trick administrators who aren't native English speakers, such as you.) There's a reason performance-optimized grooming was introduced in the same Retrospect Mac 13 release as cloud backup. It's because rewriting (not deleting) an RDB file in a cloud Media Set requires downloading it and then uploading the rewritten version—both of which take time and cost money.
  3. 1 point
    Easier stuff first... This is usually either disk/filesystem problems on the NAS (copy phase) or on the NAS or target (compare phase), or networking issues (RS is more sensitive to these than file sharing is, the share can drop/remount and an OS copy operation will cope but RS won't). So disk checks and network checks may help. But if a file isn't backed up because of an error, RS will try again next time (assuming the file is still present). RS won't run again because of the errors, so you either wait for the next scheduled run or you trigger it manually. Think of it this way -- if you copy 1,000 files with a 1% chance of errors, on average 10 files will fail. So on the second run, when only those 10 files need to be copied, there's only a 1-in-10 chance that an error will be reported. Easy enough to check -- are the reported-to-error files from the first backup present in the backup set after the second? Now the harder stuff 😉 Is this overall? Or just during the write phase? How compressed is the data you are streaming (I'm thinking video files, for some reason!)? You could try your own speed test using "tar" in the Terminal, but RS does a fair amount of work in the "background" during a backup so I'd expect considerably slower speeds anyway... A newer Mac could only help here. I'm confused -- are you saying you back up your sources nightly, want to only keep one backup, but only go to tape once a week? So you don't want to off-site the Mon/Tues/Wed night backups? Regardless -- grooming only happens when either a) the target drive is full, b) you run a scripted groom, or c) you run a manual groom. It sounds like none of these apply, which is why disk usage hasn't dropped. If someone makes a small change to a file, the space used on the source will hardly alter -- but the entire file will be backed up again, inflating the media set's used space. If you've set "Use attribute modification date when matching" then a simple permissions change will mean the whole file is backed up again. If "Match only file in same location/path" is ticked, simply moving a file to a different folder will mean it is backed up again. It's expected the backup of an "in use" source is bigger than the source itself (always excepting exclusion rules, etc). At this point it might be better to start from scratch. Describe how your sources are used (capacity, churn, etc), define what you are trying to achieve (eg retention rules, number of copies), the resources you'll allocate (tapes per set, length of backup windows (both for sources and the tape op)), then design your solution to suit. You've described quite a complex situation, and I can't help but feel that it could be made simpler. And simpler often means "less error prone" -- which is just what you want!
  4. 1 point
    Wrong -- we're now into Week 6 of working from home. ...was to issue everyone an external hard drive to use with Time Machine or Windows backup. Rest of my attempted reply just got eaten. Suffice to say: Have tried Remote Backups before -- fail for us because you can't segregate clients into different sets Keep meaning to try Remote combined with Rules -- can you run multiple Proactives using Remote tag, each using a different set, each with different Rules to filter by client name? Previously felt client list was too long for this to work, but RS 17's faster Proactive scanning may make it feasible Tags need an "AND" combiner and not just an "OR". That may not be sensible/possible -- include ability to use Tags in Rules and you'd make Rules way more powerful
  5. 1 point
  6. 1 point
    I think (not sure) that you should double-click the catalog file (in Windows Explorer) while the backup is NOT running.
  7. 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.
  8. 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.
  9. 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 😉
  10. 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.
  11. 1 point
    Dashboard actually got me excited- a more friendly user interface! But it is dog-slow (okay - I LOVE dogs, but this thing is a Basset Hound in Greyhound race.) It often hangs, gobbles resources, hangs again when trying to simply scroll, and ultimately gives little useful information. It's everything short of what we've come to expect from Retrospect - a lean, efficient, business-like and functional application. When Retrospect is invoked by a scheduled script, dashboard is the only option that comes up when you want to monitor the program itself - and the fact that there is no escape from dashboard only adds to the frustration. I get that it is well-intended - but it was executed poorly and ends up detracting from the program. I'm in the trial period (Windows 16.5) and likely will invest in Retrospect based on the last ten years of functionality and reliability with 7.7. The dashboard is the single biggest negative in my pluses and minuses column as I decide on making the purchase. Just my opinion here, but instead of the dashboard, might I suggest this approach: Develop a user interface that finally leaves the '90's behind. It would probably meet dashboard's intent with more digital elegance. Add a tray monitor - something we can mouse over and see the basics, or open and get more detail. Perhaps that goes to knowing your customers. Face it - this is a techie's software that requires a greater learning curve than the prettier faces like Cloudberry. I could be mistaken, but I suspect most Retrospect users (certainly me) would appreciate a backup solution that provides ease of both interface and access - and a tray monitor would be a simple, performance-oriented way to do just that.
  12. 1 point
    We have solved the problem. The cause seems most likely to have been Retrospect's new automatic client update feature. In any case, at some point the client software on the affected machines became corrupted or was actually deleted. In the cases we tested, if the client was removed from the sources list and we attempted to re-add it, the process failed due to an incorrect public/private keypair. We decided to just go ahead and reinstall the client software locally on all our "invisible" Windows clients, which solved the problem; we did not need to delete any client configuration files, so these must have been OK.
  13. 1 point
    Kidziti, You raise a whole bunch of points in your post. Retrospect, or any other product in its class, is not just a point-in-time purchase. You also need to "invest" in learning the product (non-trivial) and doing configuration and tuning. You also want to be sure that your investment is protected long-term because of the financial strength of the vendor. I don't know much about Storcentric (or its competition) but I will observe that backup is a relatively mature market category. One could argue that web-based backup is a different market segment than more traditional premises-based backup, but I will leave that argument to others. And what is Storecentric's strategy in purchasing Retrosepct and Drobo, as opposed to any of their direct competitors, I simply don't know. That is an issue for Storcentric of course, but it's also the kind of issue that is catnip for product management types like me. However, on the more narrow decision to purchase an ASM. I have found that I can get quite good support for my issues, even though I have not purchased an ASM. of course, when release 17 comes out, then I will have to pony up for the upgrade. More generally you have to decide if Retrospect, as it exists today, meets your needs better than the competition. Salespeople are supposed to "SWAT," Sell What's Available Today. I would ignore the statement about a new release next March, because the reality of software development is that March can easily become May or July or September. And unless you know what is in that release, you don't know how important that release is for you with capabilities that you need now, but are not in the current release. Whatever you do, DO NOT buy shares in Storcentric. There is not much information on the website, certainly not who/what is funding this acquisition strategy. https://storcentric.com/
  14. 1 point
    kidziti and everyone else, I had a telephone chat with the head of North America Sales for Retrospect "Inc." this morning (his time), in which I suggested just that. My suggestion, which he seems to like, is to simply actively market the Web-based Management Console in its no-extra-cost view-only form. You can get a brief view of the Retrospect 16.1 version of this facility in the first of these four interconnected videos. You can skip the second video (unless you want to learn how to sign up for the Management Console), and view the third video to see how to integrate the Management Console with a running Engine. The fourth video, which is designed for "Partners" (consulting organizations) shows additional two-way features available with the Add-On—which is US$49 for the Desktop Edition. The Retrospect 16.5 Add-On version of the Management Console moves the list of "backup servers" to a column on the left-hand side of the Dashboard window. Its Granular Remote Management also adds Activities and Sources and Backup Sets panels that the administrator can drill down to, as well as Scripts Management displays and the ability—for individual "backup servers"—to create and edit scripts and create destinations. Here's a 43-minute webinar that demonstrates the Retrospect Windows 16.5 version of Granular Remote Management—with a GUI resembling Retrospect Mac. At minute 27 the head of Retrospect Tech Support recommends leaving Retrospect running all the time—using the Management Console. At minute 29 he says they're moving towards having Retrospect run as a service with an HTML-based GUI. Is Server column also in the non-Add-On Web Dashboard? As the first of the four interconnected videos linked atop this post once stated, the Dashboard in the Management Console is basically an enhanced version of the non-Web-based Dashboard that kidziti and other Retrospect Windows administrators simultaneously love and hate. That non-Web-based Dashboard is a poorly-implemented feature of Retrospect Windows. It was implemented in Retrospect Windows 8 because a Retrospect-Mac-like Console proved to be impossible, but had glaring bugs that weren't supposedly fixed until 4 years later in Retrospect Windows 12.5. See this 2017 Forums post by me, which quotes the applicable 12.5.0.177 Release Notes but also quotes a reply from Retrospect Tech Support. Also read the remainder of that 2017 post's thread.
  15. 1 point
    I don't have exactly the same experience... however, I do have a caution to share: Microsoft OneDrive has a similar feature. Last I checked, it's not exactly compatible with ANY backup software, in the following sense: Backups work fine However, when you go to restore, it restores the EMPTY local folder(s) Which causes the cloud copies to get cleared out Which means you lose all of your cloud files Unfortunately, I can't place the details on this with a quick google search ...
  16. 1 point
    Interesting. I just finished discovering a specific set of bugs in Retrospect, and challenges in our router(s) and local network apps, that directly lead to the above anomalies in finding and/or connecting to clients. (Yes, all of the following has been submitted as a bug report.) I'm running a more Windows-centric network, with a little OSx tossed in, so my tools are a bit different. Tools: WireShark: shows packets actually traveling. Most useful is a filter of udp.port==497 || tcp.port==497 tcpdump (command line in linux and/or osx) - monitoring port 497 TCPview (from SysInternals, now owned by Microsoft) - sort on port. Look at what is listening to 497 and on what IP address(es) (command line) ipconfig and also "route print" In Retrospect: go into Clients -> choose a client-> access tab -> Interface -> Configure Interfaces ... and see what default interface IP address is. Things to watch for: Are UDP broadcast packets being received by clients? (eg 192.168.x.255, port 497) For multicast, are packets getting to clients? (eg 224.0.0.0/4 -- Retrospect uses 224.1.0.38 UDP port 497) Are clients responding to those packets (UDP broadcast or multicast) (initially to UDP port 497 on the backup system) If crossing subnets, is TTL set high enough to reach the client? What could possibly go wrong? Heh. Here are anomalies I've seen: Often, some app will create virtual interfaces. This includes npcap (for Wireshark etc), VMware, TAP-Windows (comes with Windows?), etc... This has led to: On some of my clients, some virtual interfaces have APIPA addresses (169.254.*) -- which makes it obvious when retrospect chooses the wrong interface to listen on! (Workaround: I uninstalled the TAP-Windows adapter as I don't need it. And I temporarily disabled npcap on the one workstation where that got in the way.) On my retrospect backup desktop, retrospect chose one of the VMware virtual adapters as the default adapter! This even though the real gig adapter has higher priority etc etc. (Workaround: create another adapter in Retrospect) The result in either case: I can't see the clients, even though ping works. I have a network security system. It regularly scans all ports on all subnets. Some (but not all) clients get confused by this, with the retroclient app hung up on an IP connection in CLOSE_WAIT status. The result: the client is never available for backups. Yet it is visible to subnet or multicast. We switched to a pfSense firewall/router. I just discovered that multicast forwarding is badly broken.(Workaround: manually installed pimd.) Similarly, UDP broadcast is often blocked by firewalls. Make sure the packets are getting through! Having fixed and/or worked around ALL of the above, and rebooted everything... I can now reliably use either multicast or subnet broadcast to connect with clients.
  17. 1 point
    It is 100% true, but it would have been more clear if the backup set name was within single or double quotes, such as: from Backup Set "Drives C D and V"
  18. 1 point
    Tags. If you set your scripts to use tags to determine what to back up, you only have to set a new/replaced client's tags once and it will be picked up by all appropriate scripts. And as David said, you shouldn't get a full backup unless that's part of the script's definition -- "Match only files in same location/path" may be the culprit here.
  19. 1 point
    You're right about Server Editions, Nigel Smith, but the OP says he licensed the Desktop Edition. As for the "soak the (presumed) rich installation" policy, which was instituted by Dantz before it was acquired by EMC, IMHO the recent failure of that "value pricing" policy in general is what led to the StorCentric acquisition. It appears business customers no longer needed to license Server Editions, because they were now using Linux machines as their servers. Retrospect Inc. put a yellow-colored note into the Windows 15.1 Release Notes saying "Linux Client: In a future update, Linux clients running on server-level Linux distributions will be treated as server clients". However, as I cautiously mentioned elsewhere on these Forums, the opinion of experts I solicited on the Ars Technica Linux forum was that it would be impracticable to distinguish server-level Linux distributions—which shot down extending the "soak the (presumed) rich installation" policy. I have never questioned Windows administrators' need for the Dissimilar Hardware Restore Add-On, just its different "value pricing" levels in the Online Store.
  20. 1 point
    Joriz. First I suggest you read this April 2019 thread—the whole thread all the way through the final post. The OP in that thread discovered that he was backing up a lot more data than he thought he was. He also found the data was mostly pre-compressed, so that what really mattered was the native capacity and speed. Second, the OP in that thread also found that the tape library was never cleaning its heads—so he was getting un-recoverable errors after only a fraction of a particular tape was used. Your "backup server" machine is quite old; are you sure whoever was responsible for it before didn't just cable-up a new tape library without finding out how to set up head cleaning? That's one reason why Nigel Smith asked the make/model question. See pages 50-52 of the Retrospect Mac 16 User's Guide for instructions on how to set up cleaning for libraries and drives. Third, you write "a manual file transfer of the same source is utilizing the 1Gbit network card". That sounds as if there might be more than one network card on either your "backup server" and/or your SMB-attached source machine—which brings up another set of questions. After you've looked into those questions, I would suggest you phone U. S. Retrospect Technical Support at (925) 476-1030; the people on these Forums are just volunteers like me‬. If your organization installed Retrospect Mac 16 within the past 30-45 days, you are entitled to free personalized support. Because it sounds as if your native language is not English, and because you posted so early in the morning even compared to New York time, it seems that you may be located in Europe. I've heard that European Retrospect Tech Support is handled by a contractor, whose personnel don't know that much about Retrospect (probably especially about Retrospect Mac). May I suggest you put your Location in your Forums profile?
  21. 1 point
    Sounds like you've got problems with the library/drive. What make/model is it? I try to use Retrospect Client on the source servers rather than SMB-mounting them onto the Retrospect server since I find it generally works better -- an interrupted/resumed SMB session is usually handled fine during, say, a Finder copy but can be death to a backup. Otherwise, try the usual troubleshooting: how fast is a Retrospect Server to tape backup (i.e. eliminating SMB from the problem); how fast is a backup of SMB-mounted share to a disk directly attached to the Retro Server (i.e. eliminating the tape drive), and so on. For best speed you may want to look at a disk-to-disk-to-tape setup... As to overwriting tapes -- we don't do that here but, IIRC, that's what the "Recycle Media Set" media action (in the "Schedule" pane of the script definition) is for. Or have you tried that and found it doesn't work?
  22. 1 point
    We are working closely with Apple and are testing each internal build as they come out. We will put out an official statement when we get closer to the release. I think we have a few more weeks before Apple posts it. Like all Apple systems, we will make sure it works with Retrospect.
  23. 1 point
    Lennart_T, I am shocked that you of all people would say such a thing (see the second and third paragraphs) about the UG. Since I'm sure you're just as tired as I am of dealing with the lack of UG updating, I suggest you write (which I've done) to Rod Harrison—the Chief Technology Officer of Drobo who probably now has some influence at Retrospect "Inc". If you want to impress him with a Swedish-stamped "snail-mail": Drobo Attn.: Mr. Rod Harrison, CTO 1289 Anvilwood Ave. Sunnyvale, CA 94089 USA However, if you are willing to enroll in LinkedIn—which I am not because of delete-finger tiredness—you should be able to get an e-mail address for Harrison there. P.S.: What Lennart_T and I said about the User's Guide not being updated is still valid; Nigel Smith's post below goes beyond what the UG says.
  24. 1 point
    Oh my, x509, it appears you're back to the same situation I responded to here in a post last fall. My first suggestion would be to follow whichever of the alternatives is appropriate from the first paragraph of that post. My second suggestion would be to update your Support Case on the problem, but this time tell Support to tell Engineering that you'll go to Rod Harrison—CTO of Drobo and probably by virtue of that position now de-facto StorCentric "enforcer" at Retrospect formerly-Inc. Engineering—if you don't get some work-around in Retrospect Windows 16.5 (which I hear is due out around 20 September). A snail-mail address for Harrison is : Drobo Attn.: Mr. Rod Harrison, CTO 1289 Anvilwood Ave. Sunnyvale, CA 94089 However, if you are willing to enroll in LinkedIn—which I am not because of delete-finger tiredness—you should be able to get an e-mail address for Harrison there. My third suggestion would be to "go with the flow", and setup the Web-based Management Console per this Knowledge Base article. Of course I haven't had to do that because, as a Retrospect Mac administrator, I've had a perfectly-adequate non-Web-based Console since I upgraded to Retrospect Mac 12 (from Retrospect Mac 6.1 on a "backup server" machine that died in 2010) in 2015. P.S.: In response to x509's post below, I'd think "royally pissed" would be expressed by the following emoji:
  25. 1 point
    FYI: You can delete the snapshots one by one. But it takes lots of time and Retrospect is "not responding" for a looong time for each snapshot.
×