Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 01/06/2012 in all areas

  1. (Jul 2021: It appears this info is still valuable for RS 18. Please tell me about any hiccups you find! I'm happy to correct this document.) (Sep 2020: I've begun updating for RS 17, and for Win10 1809 and beyond...) This document (as of July 31 2018, Retrospect Desktop 15.1.2.100) is intended to augment the information in the official Retrospect 15 User Guide. All errors are my responsibility. I do not guarantee that this applies to any other version of Retrospect; in fact, I don't guarantee anything about this at all! ? YMMV. Buyer Beware. Etc. A few items highlighted below are not certain for me at this time. Insight welcome! Preparing for Disaster A. Crucial Attributes To Record About Each Client/Host System Several crucial attributes must be recorded about any client or host system that you wish to later restore with a DRD (Disaster Recovery Disk): 1) Disk Layout Why: the DRD is currently unable to fully auto-create this info. It's up to you to do so. Get it wrong and Things Can Go Badly Partition Table Type (MBR or GPT) Number and sequence of partitions. (MOST important: is there a "System Reserved" partition, is there a WinRE (Recovery) partition, which partition is Active, and what's the sequence?) (Nice to have: the name of the 'C:' windows partition) 2) Boot method Why: The boot method for recovery must match that of the system that was backed up. The DRD is currently not aware of this when regenerating a system. BIOS or UEFI? (MBR partition tables support both BIOS and UEFI boot. GPT partition tables only support UEFI boot, with a few rare exceptions.) Where is the boot BCD info? (From experience: Retrospect will NOT complain if your boot info is not on the C partition... and it may not be backed up!) For BIOS boot, the BCD info is typically either c:\boot\BCD or on the system reserved partition, at \boot\BCD. For UEFI boot, it's typically in one of those partitions, at \EFI\Microsoft\Boot\BCD or \EFI\boot\BCD. Hint: It's a good idea to save an exported copy of the BCD store while the system is in good shape. From Admin Cmd prompt: bcdedit /export c:\bcd-yymmdd will save it. [7/31/18 update] There is some indication that UEFI but not BIOS boot information is backed up from any appropriate partition. We're in discussion on this. If you have a complex multi-boot (eg using GRUB or even manually-added BCD entries), I would suggest keeping an image of your boot disk. Retrospect uses Microsoft Windows tools for recovery; recovering non-Windows boot information is (quite reasonably) beyond the product's scope. 3) 64 bit drivers required Why: Many environments do not require 64 bit drivers. Some do. If so, you'll need a 64 bit DRD rather than the default 32 bit. I have one: unless extreme measures are taken (see below), access to our Catalog Files is on a RAID 1 internal drive pair, managed by IRST (Intel RAID Storage Tech) which uses 64 bit drivers on 64 bit Windows. 4) Custom drivers required Why: If recovery requires access to devices that need nonstandard drivers, you'll need to prepare ahead. Example: my IRST setup. Typically, custom disk drivers that can be used at boot time are downloadable either in normal "installable" form, or in what is known as "F6 Floppy" form (refers to pre-boot interruptable driver-load... TMI ) The DRD creation instructions tell you to copy these drivers to a particular place on your Retrospect Desktop machine before creating the DRD. Do it. (currently they go in <Retrospect Install Folder>/drsupp/drivers ) 5) Non-hard-drive boot methods fully supported for system recovery Why: Not all machines support USB memory key boot. Windows 7 does not fully support USB for recovery operations. You may need a DVD (even a USB DVD, strangely). B. Crucial Things to Know About the Disaster Recovery Disk This information is not documented elsewhere, AFAIK, other than the first line below 1) The DRD... Why: These attributes determine how many DRD's you may want to create and maintain. AND, you'll want to update the DRD after significant system or Retrospect config changes. Is either 32 or 64 bit, and recovers a certain range of OS versions (eg seven varieties of Win10, etc) Assumes the boot style of the host system (it appears the DRD is intended to boot both UEFI and BIOS. Not yet clear if this works properly. For now I would not make assumptions.) Contains all Retrospect configuration as of when it is created, including Devices, Clients, Backup Sets, Volumes, Selectors, Preferences, Licenses, and Automation Settings Has built-in drivers for network, USB and many other devices Why: These attributes are unknown to the DRD. You'll need to maintain this knowledge separately, available for use in case of disaster Does not know how to auto-restore system Partition Table types (Reserved, Recovery, etc), partition settings (sizes, etc), have access to catalog files on other disks, or login info to access network shares 2) Where do you keep your Catalog File? Why: Be sure you can get to the catalog file while recovering from a disaster! It's easy to move the catalog file off of your boot drive. Do it. (Or, make a copy as part of your backup strategy) In our case, to avoid other hassles, we host DRD recovery using a copy of the catalog files loaded into a USB stick. Easy-peasy. C. Before Creating the DRD Do you need custom drivers? Make sure they are in place already (see above)! For Windows 10, you need to download and install WinPE, which is part of the ADK as described in the DRD documentation. These items are not yet documented: For Windows 7, a different kit is needed, the "AIK" PRE-Win10-1809: You don't need to install the whole kit. When running the ADK setup, uncheck everything other than "Windows Preinstallation Environment (Windows PE)"... which will auto-check "Deployment Tools" Win10 1809 and beyond: You only need the WinPE addon to the ADK. (See here: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/download-winpe--windows-pe) When running the ADK setup, uncheck everything other than "Deployment Tools." Then then install the WinPE addon as described here: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/winpe-create-usb-bootable-drive Highly recommended: just before you create the DRD, do something to disable or pause all auto-run scripts! The DRD recovery environment is a "real" Retrospect environment, and will attempt to run any active scripts! (I introduced an N month delay in all scripts as a workaround, then removed it) Yes, it is possible to cancel all scripts once the DRD is running, but that can take quite a while as Retrospect goes through "preparing for open file backup" on the active scripts...) D. Creating the DRD The DRD tool wants you to locate a file, "copype.cmd" . The Retrospect team intends to auto-find this, but that's not yet implemented. The file is found in <Kit install dir>/Assessment and Deployment Kit/Windows Preinstallation Environment Bare Metal Recovery A. Preparing the System Ensure the system is set up in a similar fashion to the original system that will be restored. In particular: Boot settings so the system boots into the correct boot type (UEFI vs Legacy/BIOS. For one of our machines that supports both, I had to force it to Legacy to get everything working.) The correct Partition Table Type and Partition Layout (The DRD can create partitions, but has no ability to set Partition Types, special partition formats, detail-level partition sizes, etc.) (At first I reloaded Win10 on a system to be reloaded. The partitions were laid out very differently, and in particular a different count and sequence. Result: the recovery process wanted to wipe the contents of other data drives on the machine! Another time, the recovery immediately failed with strange VSS errors. Only when I correctly pre-set all of these elements did recovery go reasonably well. Tech Support has informed me these are known bugs (eg Bug 6109 about an invalid disk erasure warning)... however, if you have any concern for preserving drives, I urge care in restoring to ensure you don't accidentally make things worse than they already are ) B. Doing the Restore The recovery process involves several steps. Remember, I'm just giving additional notes and hints. The primary steps involve: pre-setup, run retrospect, post-restore Pre-setup: if you've predefined the partitions, you'll mostly just want to erase and reformat the 'C:' windows partition. Give it the same name that it had before to make life simple. Pre-setup: If you'll need network access to your backup sets, this is a good time to do a network-use of any needed shares. The DRD process will remember you're logged in from this point on Pre-setup: if you have other disks (eg USB stick) to attach to the system, eg containing Catalog files, now's the time to plug them in. In retrospect: check the needed catalog file(s) / backup sets. Can they be accessed (double click in 'Backup Sets'). If not, click "More..." then "Open..." to open the catalog file. Drag-and-drop of a catalog file does not work at this point to attach it. In retrospect: to do the recovery, go through the "Restore" process. I find it helpful to click on "Switch to Advanced Mode", and go through the steps one by one to be sure everything is as desired. In retrospect: before rebooting, be sure to remove the DRD disk! You don't want to just run the recovery again Post-restore: (if using Dissimilar Hardware Restore, don't leave the DRD script after finishing with Retrospect!) C. After Restore When my main host restore was complete, after reboot I got "no operating system found"... a bit scary. Solution for my situation: Boot with a Windows Recovery CD, get to a command prompt, and use these commands... bcdedit (shows boot information setup, if any. My system had none! bcdedit /store x:\boot\BCD is good to know about...) bootrec /rebuildbcd (finds windows and builds the correct boot environment) bcdboot c:\Windows /s b: /f BIOS /v [where the drive letters are what's valid in your recovery environment; "c:" is your windows volume, and "b:" is your boot volume, which could be the same as the windows volume, or could be the System Reserved partition.) ALSO of note: for bcdboot to work, you need a valid copy of the following file from the bootable normal windows environment: c:\windows\system32\config\BCD-Template If you get further errors, you're beyond the scope of this hints-doc. Lots of material is out there to assist you. All is NOT lost. Building A DRD After The Fact I didn't have a chance to build a DRD before the boot disk on our primary backup system died. Here's what worked to get around that not-so-little problem: Downloaded a Windows 10 Pro installer from Microsoft (yes, it's free... controlled by license codes and activation keys) Used a separate tool set to predefine the partition structure of the replacement drive, to match the old one. MBR disk with System, C:, WinRE in my case. Didn't put any data in the partitions. Installed Win10 Pro into the C partition. Told it "no license key" since it was already activated. It really did auto-activate when the time came. Downloaded and installed Retrospect. used the c:\ProgramData\Retrospect\Config77.dat file from my almost-totally-dead drive. This gave me a very nice working environment Installed the ADK as described above Modified a few Retrospect scripts as described above Installed the IRST drivers. Then (due to other problems I'll not discuss here) switched tactics and recovered the current catalog files from my RAID to a USB key With the USB key catalogs in place, and all other drives disconnected, created the DRD Bottom Line This all sounds so neat and tidy... I have done this writeup because my actual recovery process involved discovering the hard way that there are many undocumented aspects to the DRD process! I suspect with these notes, a Retrospect Desktop system could be easily recovered in a matter of hours. Mine... well let's just say I began recovery Sunday evening and finished Wednesday morning... (One of those times when I wish I could get paid by vendors who benefit from my bug-sleuthing skills?
    4 points
  2. As promised. The Test Client: "NIG-PC" -- Windows 10 VM, Retrospect 15.6.0, with C drive and external E drive. Both drives had "Test_Data" and "Test_Data2" directories, each with a couple of text files inside. Server: Windows Server 2016, Retrospect Multi Server Premium v15.6.1.104 Client was added by Direct IP with "Volumes" tab "Client Sources" set to "Client Desktop" -- both C and E drives were visible A new disk-based Backup Set called "Filter_Test" was created A new filter called "Filter_Test" was created, initially blank and then edited as per the following screenshots After the filter was edited, an Immediate Backup was created: Source -- "NIG-PC"; Destination -- "Filter_Test"; Selecting -- "Filter_Test". The Preview button was clicked and, once the results generated, the screenshot taken. The Immediate Backup was then cancelled to clear any cached Preview and to force a re-scan for the next test The Results "Windows folder path exactly matches \Test_Data\" -- no drive letter, so nothing is matched: "Windows folder path exactly matches E:\Test_Data" -- no trailing backslash, so nothing is matched: "Windows folder path exactly matches E:\Test_Data\" -- drive letter and trailing slash included, matches only with "Test_Data" on E and not E:\Test_Data2 or C:\Test_Data: So, what about "matches pattern"? We know from the filter dialog tip that "* matches any or no characters and ? matches any single character", but x509 had no special characters in his filter yet still got matches. Let's see what we can find out, starting with a filter similar to x509's... "Windows folder path matches pattern \Test_Data" -- matches Test_Data and Test_Data2 on both drives: "Windows folder path matches pattern \Test_Data\" -- matches Test_Data only on both drives: "Windows folder path matches pattern E:\Test" -- matches Test_Data and Test_Data2 only on the E drive: "Windows folder path matches pattern st_Data" -- matches Test_Data and Test_Data2 on both drives: Conclusion Exact folder matching requires a full path, including the drive letter, and a terminating backslash, i.e. "E:\Test_Data\". The "matches pattern" condition includes invisible "*"s, both prefix and postfix, i.e. if you enter "st_Data" it is actually "*st_Data*". That may be what you want, e.g. the same folder name at different levels of the directory structure across multiple drives on a client, but could also greatly widen the matches beyond what was expected. As always, the more explicit you are the closer the filter results will match your wishes. Vagueness on "includes" can massively increase backup resource requirements, vagueness on "excludes" can result in important data being missed. So test, test, test -- and be careful out there! Note Yes this was all done with "includes" whilst x509 was having trouble with "excludes" -- that's simply because I think it is much easier to see none, one or two ticked boxes amongst a column of unticked in a fuzzy screenshot than to spot the gaps in a line of selected items. But the conclusions above also apply to "excludes", and it's simple enough to verify for yourself if you doubt it. Hope that helps someone!
    3 points
  3. David, your condescending comments aren't needed here. Martin (and others, myself included) are frustrated at this slowness, and a little venting is not out of order. I don't understand why you feel the need to carry water for Dantz - if you don't have anything positive to contribute, you aren't required to post.
    3 points
  4. 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
  5. Just installed this update and tried the same Duplicate 'Replacing all contents' from the client to the Retro server machine. This time it works as it should.
    2 points
  6. Perhaps you and David could form a club? If there's T-shirts, I'll join!
    2 points
  7. The paragraph above, in my first post in this thread, is the only thing I wrote that could be considered "rude and disrespectful". But it had the effect I intended, which was to get you to supply the missing information in a post directly following it. Once you'd done that, Lennart_T and I and Nigel Smith were able to diagnose your problem—which is why I wrote "Do you see how much better help you get when you calm down long enough to explain what you're trying to do? 😀" at the top of my next post in the thread. Nobody can give you "an idea whats going on here" if you don't supply the necessary information, and I will always consider it "rude and disrespectful" for you—or anyone else—to expect people on these Forums to do so. You were probably very frustrated when you wrote that OP, but I don't consider that a sufficient excuse. You should try volunteering to answer other administrators' questions on these Forums; you'll soon understand my attitude toward administrators who don't supply the necessary information. You will also develop a "psychic" ability to read an administrator's "tone, demeanor and thoughts just by reading a few words on a screen", and by reading his/her past posts as well—as I did in this thread to guess what you were doing. I'm sorry to inform you that employees of Retrospect "Inc." haven't been reading these Forums for the past couple of years, and—unlike some other websites—there aren't any volunteer Forums administrators. So if you want to make—after 3 months 😲—a complaint about me, you'll need to create a Support Case for the head of Retrospect Tech Support to read. Here's how to create a Support Case for a bug—the closest equivalent; select "Forums" in the appropriate drop-down.
    2 points
  8. OK so, life in my hands (and knowing a workmate had just arrived at the office, so could press buttons if needed), I connected to the remote VM and logged into Windows. RS Client was running, and I could turn it off and on again. Ctrl-Alt-Del, Task Manager, found "retroclient.exe", "end process". Launched Retrospect Client, which showed Status as "Off", and the "Protected by..." checkbox greyed out. Spinning wheel every time I tried to interact with it. File C:\ProgramData\Retrospect Client\retroclient still present from before. After 5 minutes of "Program not responding", clicked the "Close program" option. Launched Client again, this time "Run as admin", same results. Ended process. Messed around with the retroclient file, still not launching. In Task Manager's "Services" tab, found "Retrospect Client", right-clicked, "Restart service". (Interestingly, that rotated the retroclient[.logn] files and created a new retroclient file.) Launched Client, everything A-OK! So I think that's your alternative to a reboot -- Task Manager->Services and "Restart" the "Retrospect Client". You don't even have to kill the Retrospect processes (Sys Tray, Inst Scan). Would love to hear how you get on next time your wife's machine has this problem...
    2 points
  9. pjreagan, How about the comparative number of files backed up, vs. the total bytes? Lots of smaller files means a slower backup and compare than fewer larger files. If there's a significant difference in the processor speeds between "AG-04" and "DD-13", that will also affect the Retrospect "client" backup speeds. This post in a 2017 thread, especially the first two paragraphs (the P.S. mostly rules out speed of the "backup server" for "client" files), covers the first part of experiments I ended up doing that have a bearing on this. This post in that same thread, and the one following, covers the rest. This post near the end of the same thread discusses my hypothesis on slowness of "client" backups. P.S.: This ArsTechnica Mac forum post says "My 2012 Era iMac with 1Tb Fusion Drive is starting to really slow down. It seems like when the drive is nearly full, the physical drive doesn't like to spin up anymore. ugh."
    2 points
  10. Wha is an "august Documentation Committee"? Sounds like fake news, if you ask me.
    2 points
  11. The QNAP NAS is a new Source to Retrospect which it has never seen before so will try to do a backup of all the files it finds there regardless of whether you think Retrospect has seen them before. The reasons are covered in more detail elsewhere on the forum but in short, without doing a byte-by-byte comparison of the files which Retrospect does not do, Retrospect has no way of knowing if a file now on QNAP is the exact same file that was on the Synology. Once the first full backup of the QNAP NAS is complete normal operations should resume.
    2 points
  12. Excited to report that I got my Retrospect backups fixed now as well !! So, disabling the "Save space and download files as you use them" setting did not work for me. So in addition to that, I tried disabling OneDrive altogether (Unlink PC/account and then remove the entire OneDrive folder) and then linking my account again which then again downloaded all files. The next Retrospect scheduled (proactive actually) run then succeeded with 0 errors or warnings ! This worked now on 2 machines already, so will try kids laptop next, but pretty confident this will work as well. Thanks to the folks active in this thread !
    2 points
  13. Ok, I did some additional debugging and I found the issue: It's OneDrive. OneDrive has an option (don't know if it's new with 1803) that gives you the possibility to only actually download a file from OneDrive to your computer if you actually use it. All files in the OneDrive folder are shown as being present, but they are not actually physically present on your computer. So they are some sort of link. The explorer shows a cloud symbol with these files. As long as one such link is present on the drive (even if it is in the Recycle bin) it will cause the -1103 error. Scanning will be interrupted as soon as the scan engine hits the OneDrive folder. On both machines I turned the option off in OneDrive settings, which caused all OneDrive files to be downloaded to the computer, and both are backing up properly now, without errors. Also checked the machines that never showed the issue, they all have this OneDrive option set to off.
    2 points
  14. Oh well, #sigh I have a few Macs. All on WIFi All on DHCP They have to be this way, because they roam from office-to-office, client-to-client, home-to-work-to-home ... like laptops do. The error -530 and associated -519 has be around in almost every version of retrospect I have used for the past 20 years. I can never find the solution, apart from a full client reinstall, and I can not be doing that every week TBH! Is there ever going to be a stable answer? Each Mac, Client and Server has no firewall or anti-virus FYI. The fixed desktop Laptops that do not leave the office have no issues. The laptops returning to the office login automatically to the WIFI and have no network issues for everyday work; email, www, ftp, server shares, printing ... what so ever. Server: Mac OSX 10.11.6 Client: OSX 10.12.6 Retrospect 13.5 Please don't say 'upgrade to the latest version of Retrospect or I may have to slap you :-) That has never been an answer to this issue.
    2 points
  15. Assuming you are talking about a "Disk Backup set", this is what you do: Exit Retrospect. Move (not copy) the folder with the *.rdb files to its new location. Launch Retrospect Configure-->Backup Sets. Change the location in the "Members" properties by clicking on the "Browse" button. See attached picture.
    2 points
  16. It will not backup the files again.
    1 point
  17. I'm constantly repeating similar to our Mac users. FileVault (macOS's similar feature) may be great for securing their files, but makes frequent usable backups even more important because a failed drive usually means the loss of the data on it. So we're on the fence whether to use it -- we have way more failed disks than lost/stolen laptops and work data isn't particularly sensitive/valuable so, in what is virtually a BYOD environment, it's up to the user whether they want the extra security for their personal stuff and if so they can take on extra responsibility for their backups.
    1 point
  18. Hi, It would be real time saver if we would be able select multiple snaphots to forget in a disk based backup set. As it stands now you can only select one at a time, shift or control click doesn't work. Thanks, Johnny Mac
    1 point
  19. 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.
    1 point
  20. 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.
    1 point
  21. 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.
    1 point
  22. 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.
    1 point
  23. Replying months later to Lennart_T's post, I finally (never mind why!) got around to doing a grooming operation. It was a success. Here is the selector I used in the groom job: Note that the S-1 ... folder never should have been backed up. The System Volume folder was explicit.y excluded in my universal "Always Exclude" selector. Just in case the System Volume exclusion didn't work, I also excluded files matching pattern 32{* and *{380* that are either 12 GB or 50 GB in size. Before the groom operation I did a Find Files operation on the Media dataset, to identify files and folder to groom out. AFter the groom operation, I did another Find Files operation to confirm that all those files were in fact groomed out, except for an S-1* folder inside the $RecycleBin, which should never have been backed up. (But I'll clean that up.) The groom operation recovered 345 GB and 15479 files. After I get some more experience with this grooming selector, I will incorporate it into the backup script. x509
    1 point
  24. By default, Retrospect Client will bind to the first available active IP address. In a dual-NIC setup (e.g. network card and wireless in a laptop) that "first available" can vary. So you'll need to tell the client which IP to bind to -- see this page for details. Obviously, only works for static IPs. Luckily it sounds like that's what you are using. That might be enough to get you going. Otherwise, could you re-post the problem but refer to machines as "clients" for the ones you want to back up and "server" for the one doing the RS backup? Like David, I'm getting a bit confused as to what's what!
    1 point
  25. David, I had to laugh when I read your suggestion. One of the HARDEST MOUNTAINS YOU WILL EVER CLIMB is to try to convince the management of a small software company to hire a good tech writer to create and maintain their documentation. They see this as a straight money losing proposition. I've tried with different companies over the years, and if there is a convincing argument I've yet to find it. They never think the subsequent decrease in support costs and increase in customer satisfaction will make up the difference. As with most companies, Retrospect's manuals fall into the category of "informative but not instructional". They tell you what the program can do, but not how to use the program to achieve the results you want. It's better than nothing, and you've got to appreciate the volume of the docs, but it's sometimes a treasure hunt to find what you're actually looking for. It is quite expensive to do it right. If you want to see somebody who does it right, and is much bigger than Retrospect, take a look at Fortinet. Just Google "Fortinet Cookbooks" and get on the Fortinet Youtube channel. It's phenomenal. Mark
    1 point
  26. bradp015 and Lennart_T, bradp015 can as of Retrospect Mac 14.6 do what he suggested in his OP, so long as he is simultaneously backing up a different Favorite Folder on the same drive in each script. He could divide his whole disk into Favorite Folders, which only apply to Retrospect, and have his two scripts back up the Favorite Folders in a different order. Alternatively bradp015 could do what Lennart_T suggests, with a Backup script and a Copy script. However he should be sure to assign the same Activity Thread, in the Summary tab for the Scripts, if he schedules the two scripts so that they could possibly overlap in execution. If he doesn't make sure to do that, the Copy script will ignore new or changed files that are being backed up—since it uses a Catalog File that is not updated for the Media Set until the end (barring any optional Comparing) of the Backup script run. P.S.: On 10 January 2017 I suggested in this Product Suggestions—Mac OS X thread that a modest enhancement to Retrospect would enable overlapping a Backup to a particular Media Set with a Copy Backup or Copy Media Set from that same Media Set as the source. That enhancement assumes that the Copy script would be scheduled at least a minute after the Backup script. On 2 April 2017 I converted that suggestion into Support Case ##54601 for a Feature Enhancement. That Support Case has been closed, with no evident action taken on it by Retrospect engineering since then. Considering that Retrospect 15 now enables multiple Activity Threads (Execution Units for Retrospect Windows) even for the Desktop Edition, IMHO Retrospect engineering should reconsider that enhancement for Retrospect 16.
    1 point
  27. bradp015, I agree that it looks as if you have enough space on "4T HD" for another copy. The one thing that occurs to me is that you have two "Retrospect" folders on that drive. even though one of them is underneath the "NO USE SFA 3SAFE 4t 111116" folder. IME the parts of Retrospect that deal with creating Members on disk drives are programmed to either detect existing "Retrospect" folders or to create new ones. I'd hazard a guess that those parts get confused when there's more than one "Retrospect" folder on a drive. I'd suggest that you Finder-move the "SFA 3SAFE" folder that's two levels inside the "NO USE SFA 3SAFE 4t 111116" folder so that it—and its subsidiary "1-SFA 3SAFE" folder—are directly within the "NO USE SFA 3SAFE 4t 111116" folder, and then Finder-delete the "Retrospect" folder that the moved folder used to be underneath—along with the "Retrospect" folder's contained 0-byte "Backup Media" document. If you ever need to put the moved copy of the "SFA 3SAFE" folder back into action, you can first re-create a "Retrospect" folder and then Finder-move that "SFA 3SAFE" folder back inside it. Come to think of it, maybe the 0-byte "Backup Media" document is a marker to tell Retrospect that the "Retrospect" folder that contains it also contains a Media Set Member folder. If so, it would explain why Retrospect would get confused when it found more than one "Retrospect" folder containing a 0-byte "Backup Media" document on the same disk volume. Yes indeed, that's the sort of kludge I might have devised myself back when I was an applications programmer.
    1 point
  28. AFAIK you don't necessarily need separate client vs server DRD's. I'm working to get clarification on some of these things from the tech support team. They are definitely aware of the confusing documentation etc.
    1 point
  29. Ahari, All those engineers working on a fix for a newly created problem, those engineers need to be paid. Retrospect doesn't stay in business with fresh air and rainbows. They need revenue. Either pay for upgrades. How would you feel if upgrades were "free" because you had to pay a monthly subscription fee to Retrospect? More and more companies are moving to the subscription model because future revenues are more consistent.
    1 point
  30. Hi All, Just another quick update. We are still investigating these errors, most of which appear to be tied to One Drive, but it seems not necessarily always tied to One Drive. The results from the internal investigation indicates that the problem is a bug introduced by Microsoft. Just to give a simplified overview, when using VSS we aren't ever actually backing up your files, we backup Shadowcopies of your files. In the case where we run into problems, after we access the bundle of Shadowcopies that Microsoft is preparing for us (after using standard VSS calls), we encounter write access violations. So VSS prepares everything, gives us this blob of data, and then says we aren't allowed to access it. What's also strange is we aren't actually writing during the scan, we are just reading the data. We confirmed that this isn't just bad error mapping on our part, we are actually receiving write access violations. We are implementing some changes that will be a part of the next release (v15.1) which should allow the backups to continue beyond this error. This is currently scheduled for release later this week. We will continue to work with Microsoft to address the issue further, whether that means changes on our end, or a patch on their end. We really appreciate the feedback from this forum thread, as well as the all of the information submitted to us via web tickets. Thanks, -jeff
    1 point
  31. Lucky_Phil and others, I am now seeing similar problems. When the script runs from the scheduler on the host (local) computer, it fails during a scan of the C: drive. No problems with other drives on the host computer. Running the script via the Run pull-down will run successfully. I believe this may be a different problem than the client issues, although both are throwing the same -1103 error on the host. The open file backup on the client C: drive is failing and throwing VSS errors in the clients' event logs. The error propagates back to the host as a -1103 error. This problem only occurs on the C: drive, not on other drives on the client. For the problem backing up on the local machine, I can find no related problems in the windows event logs.
    1 point
  32. Sure, I am the Backup, I don't see why not. The only possible glitch I can see is that what you can now purchase is Retrospect Mac 15; Retrospect Mac 14 is obsolete. The cumulative Release Notes for Retrospect Mac 15.0 say "New: Support for LTO-8 tape devices", so the chances are the support for LTO4 devices is still there. In case it isn't, I imagine you can go through Retrospect Sales to get a license code for Retrospect Mac 14.6, which can still be downloaded. The one thing I would caution you about is that the Desktop Edition only supports a single non-autoloader tape drive. If your LTO4 tape drive is fancy-shmancy, you may have to purchase the Single Workstation 20 Client Edition—which is substantially more expensive. You can probably negotiate this with Retrospect Sales, with whom I have no connection other than as a customer.
    1 point
  33. First, this post by the very knowledgeable Lennart_T (formerly known as Lennart Thelander) says there is a 1TB limit on File Backup Sets. They do exist, but they are a pre-Retrospect-Windows-8 facility you should not use; you should be using Disk Backup Sets instead. Second, the "Scalable data protection" feature announcement for Retrospect Windows 12 says"Retrospect is now certified to back up 1 billion files per backup set, 100 TB of data per backup set, and 50 million files per device."
    1 point
×
×
  • Create New...