Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 03/09/2016 in all areas

  1. 3 points
    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, 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 the ADK as described in the DRD documentation. These items are not yet documented: For Windows 7, a different kit is needed, the "AIK" 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" 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?
  2. 2 points
    Wha is an "august Documentation Committee"? Sounds like fake news, if you ask me.
  3. 2 points
    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.
  4. 2 points
    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 !
  5. 2 points
    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.
  6. 2 points
    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.
  7. 1 point
    This might help: https://www.retrospect.com/en/support/kb/scanning_incomplete_1103
  8. 1 point
    insont, That's good, because I just found a 15 May 2018 Knowledge Base article change confirming what you've been saying. The paragraph "Mac Customers: Please note that Instant Scan is not supported with APFS." has been added below the first paragraph in the KB article "Instant Scan Frequently Asked Questions". which is under the catch-all heading "Resources" in the KB . That first paragraph begins with the sentence "Retrospect 10 for Macintosh and Retrospect 8 for Windows introduced a new feature called Instant Scan." This section of the permalinked old version of the Wikipedia article says those versions were introduced in 2012, so the original article almost certainly dates from sometime shortly after that year up through April 2015—when the companion article "Instant Scan Advanced Options" was published. Sorry to have previously expressed doubt, Martin. Pretty sneaky announcement there, Retrospect Inc. ; you didn't even point Martin to it in your final reply to his Support Case.
  9. 1 point
    I have some fairly complex selectors, and editing these via the UI is somewhat cumbersome. Is there a way to export the selectors in a text format that can be edited and rearranged in a simple text editor, and then reimported? I tried the "export" function, which produces a .rxx (Retrospect Exported Selectors) file. The format is binary and doesn't start with a known file type signature.
  10. 1 point
    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.
  11. 1 point
    You could set all tapes except one as "lost" and verify that tape. After the verify you set all the tapes to "found" again. What if you must do a restore? (After a hard disk failure, for instance.) If you are unlucky, there is (at least) one file on each tape, so it would take "about 3 solid 24/7 months to complete". I suggest you start a new backup set and keep the current set somewhere safe.
  12. 1 point
    To be honest: I really don't understand what's the purpose of all these forum posts about editing a Wiki article about Retrospect... In my opinion these posts all are very lengthy and hard to read and of no use and interest to users of the software.
  13. 1 point
    On Retrospect 15.1.0 I get the same results (I'm viewing the output in Notepad++ instead of Excel) as Lucky_Phil. What I did was: Reports > Session Contents Select Backup Set then select Session File menu then Export... For Select which data to export: choose the Backup Set and click OK In the Export Sessions dialog enter a filename and click Save
  14. 1 point
    IMHO what ShadeTek wants is some version of what barup wanted in the OP of this thread. That would probably be because the tapes that are members of a particular Backup Set are not externally labeled as such in ShadeTek's installation. If so, then he/she cannot do "putting in all 8 tapes in one go". There is a facility in Retrospect Mac that allows one to see all the members of a particular Backup Set (called a Media Set in Retrospect Mac), but I don't know if it works for tapes—which I haven't used since 2010—much less what the equivalent facility would be in Retrospect Windows. If ShadeTek wants such an enhancement to Retrospect, here is why and how to submit a Support Case to request it.
  15. 1 point
    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.
  16. 1 point
    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
  17. 1 point
    Hi x509, This will depend on the results of the investigation. If it looks like something is broken we'll submit a bug report. In fact, depending on what is broken we may have to submit a bug report in order to get it fixed. Cheers, -Jeff
  18. 1 point
    Hi All, Thanks so much for all of your input. We have reproduced the issue in house, we are investigating an appropriate fix, indeed it does appear to be due to a change in Microsoft's One Drive. I'll keep you all updated on our progress. -Jeff
  19. 1 point
    Just to throw out an idea after catching up with this thread, you might also want to investigate the settings in Control Panel | Sync Center in relation to One Drive, as well as anything else. Sync Center might have a bearing on this. I saw a bulletin regarding a completely unrelated application yesterday that encountered errors caused by the Sync Center. Then I read another article today discussing how One Drive syncs files and folders to the MS cloud. Now this thread to bring it full circle. I'm going to continue to watch this thread, and want to say that I really appreciate the extremely professional community discussions on this Forum. Bravo.
  20. 1 point
    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.
  21. 1 point
    Andrew Kinnear, I haven't done this myself, just read the User's Guides and half-experimented using my own Retrospect Mac 14.6 "backup server". However, for a media set named "Media Set Example", I think the answers are: [1] It should be fine to use CCC, provided you copy the parent "Retrospect" folder and the "Media Set Example" folder within it as well as the "1-Media Set Example" data file within the "Media Set Example" folder. After you've done the cloning, click the Media Sets category on the left-hand side of the Console, click "Media Set Example" in the list pane, and click the Members button above the detail pane below the list pane. You can then click the the only line in the detail pane (you said you have only one member for each media set), which should be "1-Media Set Example", and after that click the pencil icon at the bottom left of the detail pane; doing so should allow you to redefine the location of "1-Media Set Example"' as being the cloned file instead of the original. After that you shouldn't have to do a Rebuild of "Media Set Example", but if you do the instructions are under the heading "Rebuilding a Media Set"—which is on page 220 of the Retrospect Mac 13 User's Guide (the P.P.P.P.S. of this post explains why I'm looking at that UG instead of the Retrospect Mac 15 UG; the only attempt at an explanation of the functionality I've just described is at the bottom of page 15 of the old version). [2] AFAIK no functionality should be lost for "Media Set ExampleSmall&Cryptic". The reason it shouldn't be is that the snapshot—the basis for most of the functionality—is part of the "Media Set ExampleSmall&Cryptic" Catalog File, which your Copy Media Set script will have created as essentially a duplicate of the "Media Set Example" Catalog File. If there is loss of functionality, IMHO there should be mass developer suicides (insert appropriate smiley here) in Walnut Creek CA, considering that the Copy Media Set type of script was introduced in Retrospect Windows 7.5 by 2008. [3] I don't use software compression or encryption in my humble home installation of Retrospect Mac (I keep last week's rotated USB3 backup disk in my bank safe deposit box), but AFAIK they should be applied if you've specified them when defining "Media Set Example—Small&Cryptic".
  22. 1 point
    In short an Archive script is a Backup script but with the additional option to delete the copied files from the Source once they have been copied to the Destination and verified.
  23. 1 point
    That would be correct for your setup. My NAS is setup for multiple users with restrictions on which users can access which shares so maintaining the Owner, Group and Permissions on files and folders becomes necessary. I ran a test duplication using Replace Entire Volume with two old Buffalo LinkStation as the destinations and it would appear to be expected behaviour from Retrospect to delete and recopy everything when the destination physically changes. (Duplicate to 'A'; Copy from 'A' to 'B'; Duplicate to 'B') It was having a few of these incidents myself with my camera raw digital images that convinced me to use backup instead of duplicate. If this one has had the same change of destination I suspect it will have the same issues.
  24. 1 point
    Every time a backup is run Retrospect will create a .session file, containing details of the files from that backup, in the same folder as the .rdb files. When Retrospect does a Catalog rebuild it will read these .session files for the necessary information which is faster than reading the individual.rdb files. If you need to perform a thorough rebuild it is necessary to delete the .session files. (During the rebuild the .session files will be recreated.) This feature for faster Catalog rebuilding was added in Retrospect 11 for Windows and Retrospect 13 for Macintosh.
  25. 1 point
    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."
×