Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 06/20/2018 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. 1 point
    We have released a patch that users of Retrospect 14 and earlier can use if backups incorrectly show a deferred status. https://www.retrospect.com/en/support/kb/deferred_date_on_mac You will install a new Retrospect console and continue to use your earlier Retrospect Engine. This fixes the issue without purchasing an upgrade.
  4. 1 point
    bradp015, You fail to understand the overall idea, which is that you will run a Copy Media Set script once and then run a Copy Backup script daily. I don't have time to write a post describing the procedure just for you, but here is a post I made in September 2016 describing a superset of that procedure—one for creating and maintaining a running copy in the cloud of backups to a local Media Set. In steps 1) through 6), ignore anything concerning Grooming or a cloud account—which means you can essentially convert steps 3) and 4) into whatever it takes to set up you new local duplicate-of-the-original Media Set. In both steps 5) and 6), don't check No Verification unless you like living dangerously (cloud providers are supposed to have such error prevention that lengthy-and-expensive verification isn't necessary). Ignore step 7).
  5. 1 point
  6. 1 point
    This might help (even if the mentioned screen dump seems to be lost in the mists of time):
  7. 1 point
    Here you go. https://www.retrospect.com/en/support/kb/moving_retrospect_from_one_macintosh_backup_computer_to_another_macintosh_backup_computer
  8. 1 point
    Guys, Sorry for going silent on this thread. I do have Instant Scan on. I'm working on some suggestions from Retrospect support. As soon as I have something definite, I will report it here. So far, if I run an immediate backup, the backup works properly. x509
  9. 1 point
    JamesOakley, It sure as heck gets more of their attention and memory than simply posting about a bug on this Forum, which nobody at Retrospect Inc. reads anymore (per CEO J.G.Heithcock). That fact is AFAIK one reason Retrospect Inc. instituted Support Requests; previously the organization had a sad record of often taking 4 years or so to fix bugs. Besides, how much time do you really need to spend on a Support Request? After supplying installation details that they definitely need to isolate the bug, all you need to do—as the post linked-to in the preceding paragraph says—is to copy-paste paragraphs from your post(s) here. You can upload screenshots as part of the Support Request. If you really want to get someone's attention, you can also phone Werner Walter as indicated in this post, or even send an e-mail to Brian Dunagan as indicated in this post. However I'm afraid that Brian truly needs to devote his full attention to organize the engineers in fixing this "bad release". I'm beginning to think that x509 may be right; that, in order to "play catch-up ball" after this situation (third and fourth paragraphs), Retrospect Inc. may have entrusted some enhancements to R. non-V. to developers in China—without ensuring thorough testing. I think I can safely say that the old-timers at Retrospect Inc. will be sufficiently be scared by knowing that they have put out a "bad release". If you read between the lines and follow the references in the second and third paragraphs of this article section, you will realize that Retrospect Mac practically "went down the tubes" as a product in 2009-2011 as a result of the "bad release"—one that was really the fault of EMC management rather than the developers— of Retrospect Mac 8.0. P.S.: In last sentence of first paragraph added link to Engst 2009 TidBITS overview of Retrospect Mac 8, where "Cracks in Retrospect’s architecture started to show ...." reflects delays in fixing bugs.
  10. 1 point
    This is a pretty serious regression since the 12.x versions. Certain errors (specifically including a client being unreachable) no longer fail elegantly with an emailed report, but cause the whole engine to hang so that nothing is backed up. Further more, the hang is serious enough that it can't be restarted from the dashboard - it requires the task manager with elevated permissions.
  11. 1 point
    x509 Do you have InstantScan running on the drives in question? I have encountered situations before where, although InstantScan is active and reports no detectable errors, the volume databases stops updating and so as far as Retrospect is concerned no new files have been added files have been added, changed, or deleted on the volume. When a file is added, changed or deleted the volume database should be updated fairly soon afterwards so if the file time stamp of the volume database is not updating then InstantScan is not updating. The InstantScan volume databases are in the C:\ProgramData\RetroISA\RetroISAScans folder. To reset stop the InstantScan services, delete the volume databases, the restart the InstantScan services.
  12. 1 point
    According to the Blog, 15.6 was announced on Tuesday. https://www.retrospect.com/en/blog/2018/10/16/retrospect_15_6 It's available for download now. https://www.retrospect.com/en/support/downloads However: My 15.5 Desktop/Pro does not see an update available Mayoff hasn't announced it here QUESTION: Is the new version safe to download and use?
  13. 1 point
    An update will show in Automatic Update and a manual check for updates from within Retrospect a few weeks after initial release. This presumably to allow the early adopters who go looking for the update to find any problems before the rollout to the masses via Automatic Update. As for safe to download and use, well I downloaded and installed it and so far the update has run without problems for me. (YMMV.)
  14. 1 point
    Actually Monafly isn't misreading what he/she is reading in the Grooming dialog. Retrospect Mac 12 added a Months to Keep entry box to the Grooming dialog, which is described on page 9 of the Retrospect Mac 12 User's Guide. A quick test on my "backup server" shows that (as I expected for compatibility) clicking the Groom to Retrospect Defined Policy button causes Months to Keep to default to 12. Unfortunately that page was part of the "What's New" chapter, and the august Documentation Committee has adopted for the last 4 versions of the UGs a policy of totally overwriting the last version's "What's New" UG chapter with whatever is new in the current version of Retrospect—without copying the last version's "What's New" content to another UG chapter. I have mentioned that policy in other posts; a frank appraisal of it would require me to use the words "heads" and "wedged" and "up" and the third-person plural possessive of the name of the human excretory orifice, which of course I'm too polite to do.
  15. 1 point
    This might help: https://www.retrospect.com/en/support/kb/scanning_incomplete_1103
  16. 1 point
    Thanks, you found what I was looking for, but didn't find. A bit further down in that article: "LTO uses an automatic verify-after-write technology to immediately check the data as it is being written,[42][43] but some backup systems explicitly perform a completely separate tape reading operation to verify the tape was written correctly. This separate verify operation doubles the number of end-to-end passes for each scheduled backup, and reduces the tape life by half."
  17. 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.
  18. 1 point
    Well, I did write support to ask if they had plans to fix Instant Scan in the future or if they'd given up on MacOS, and got some encouraging news: /Martin
  19. 1 point
    derek500, in this 2015 post, gave me the solution. See the remaining posts by me in that thread for further discussion. Although I'm still using Retrospect Mac 14, I routinely use that undocumented dragging-in-the-Details-panel-of-the-script-Summary trick whenever I Remove and re-Add a source. See further posts by me in that thread for an explanation. There's a limitation for local Sources because you can't easily Remove them, as discussed here and in posts that follow it. In any case, the first paragraph of this following post is my explanation of precisely what is the nature of the "alphabetical order" that Retrospect follows in backing up Sources within a script.
  20. 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.
  21. 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.
  22. 1 point
  23. 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.
  24. 1 point
    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.
  25. 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.
×