Jump to content

Leaderboard

The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation since 09/18/2020 in all areas

  1. 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
  2. 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
  3. Perhaps you and David could form a club? If there's T-shirts, I'll join!
    2 points
  4. 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
  5. 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
  6. Good Morning, I have been engaged in a long project to design a way to harden a Synology NAS so it can be used with Retrospect to make it ransomware-proof. I decided early on that I should make notes. Good thing. This is the result of months of work, and I hope it's useful to many users and dealers. Please leave notes and critiques, which I'll try to address as we go along. Good Luck, Mark Hardened Synology NAS.pdf
    1 point
  7. David Why don't you stick to the subject of this thread, which it so happens is not a personal grudge you have against Retrospect that dates back to 2017? It's because you have absolutely no pertinent information or knowledge of this subject at all, as you admitted in your first response. Start your own forum thread and beat that dead horse once and for all, leave this topic to those who are interested in the subject. Mark
    1 point
  8. David, I'm not soliciting hysteria over whether the post should have been made. Rather, I was more interested in a productive discussion about factual or procedural errors or improvements. AFAIK this post does not violate Forum rules, and this and and other similar posts should be encouraged because it expands the functionality of the product. You personally display a deep distrust and dislike of Retrospect and StorCentric, which is a recurring theme in nearly every one of your posts. Why are you here? Just asking, but I read a lot of your posts and they're nearly all non-responsive. It's interesting in a weird way. Mark
    1 point
  9. (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?
    1 point
  10. I manually started the Retrospect Engine and it's PID remains the same for 10 minutes. When I launch the application the Engine goes to a high CPU use level and then crashes. I then removed and backed up the Retrospect Folder from /Library/Applications support, did a full uninstall, restart and reload and now the Application and Engine are running properly, I then stopped the engine and copied back the Retrospect Folder from a backup and then problem returned ! I then discovered through trial and error that the Config80.dat file was corrupted so I deleted it and renamed the config80.bak file to config80.dat, restarted the engine and now everything is working. Thanks Nigel.
    1 point
  11. We have confirmed this is a bug and we plan to fix the problem in an upcoming release.
    1 point
  12. Sounds like the Retrospect Engine is spontaneously quitting/restarting for some reason. Try stopping it, and turning off "Launch on System Startup", in the Retrospect pane of System Preferences. Restart the computer so you are working off a clean sheet. With Activity Monitor open, start the Retrospect Engine. Note the PID in Activity Monitor, go away for 10 minutes, come back and check again. If the PID is the same then the Engine hasn't quit, so try launching RS Console and seeing what happens. You may even find that switching to a manual start cures the problem -- IIRC there was someone last year who was seeing similar, and it appeared to be a timing issue where Engine was active before an external device and got into an endless restart loop when the device appeared. Failing that, keeping an eye out for the PID change (indicating a restart) which will give you a time period before that to check Console logs for problems. Try all the above in "standalone" mode -- disconnect any external devices bar keyboard/mouse/display, unplug the network and turn off wireless. It may be something totally unrelated, so keep it as simple as possible. It also looks like you didn't completely remove all preferences -- there are scheduled activities showing. A complete uninstall/re-install might help, if only for troubleshooting.
    1 point
  13. SOLUTION - rebuilding the catalog file has fixed the problem. Note: Fast catalog rebuild option was enabled during archiving, so I was able to rebuild from the last tape in my media set. Be aware that Retrospect will ask for another tape (last number plus 1, which doesn't exist (!!)). This is Retrospect's way of telling you the rebuild is complete and you should hit the Stop button. Restore of the volume is underway!
    1 point
  14. Central US, so where I am it's almost time to head for the pub. Cheers!
    1 point
  15. backy, Consider using the Data Compression (in software) option (page 357 of the Retrospect Windows 16 User's Guide) on your Transfer scripts. That'll save tape space. OTOH the option may slow down your Transfer scripts if you don't have a powerful "backup server" machine; the ancient HP DAT 72 tape drive that I use for backing up my (now-deceased) ex-wife's old Digital Audio G4 Mac has a hardware compression capability, but ancient Retrospect Mac 6.1 doesn't support it. I learned about Storage Groups to fully answer other administrators' questions, starting with this March 2019 post in a thread whose OP asked about running multiple Backup jobs to the same Backup Set. I was curious enough to run a couple of experiments on my own home installation, which is how I learned about how Storage Groups really work but also about the limitations of their current Retrospect Mac GUI. If you liked my "amazing" post that much, you could click the "Like" heart icon at its bottom right. The head of Retrospect Tech Support runs a contest every few days; I enjoy competing for "most liked content". Lennart_T's second post in this thread is also pretty helpful, so maybe you should "Like" that post too; competition is good.😁 P.S.: If you're going to give the Backup/Proactive script and the Transfer script for a particular Source the same Execution Unit, I wouldn't use the New Backup Set Backup Action. I haven't used it, but it sounds like a potential complication.
    1 point
  16. That's bad. One workaround would be to schedule both the backup and the transfer to the same execution unit. Then the backup will have to wait for the transfer to finish (or vice versa).
    1 point
  17. I think Retrospect will wait for the transfer to finish. You don't even have to update the scripts. Just use the "New Backup Set" backup (or transfer) as outlined here, and Retrospect will update the script for you: https://www.retrospect.com/en/documentation/user_guide/win/fundamentals#backup-actions
    1 point
  18. oslomike, I don't understand how your different product for daily disk backup could achieve the result you said you were looking for in this up-thread post. Nigel Smith's post further down the thread basically said you would have significant difficulties achieving that automatically with date-based rules, which why I suggested in the next post that you achieve it with minimum manual effort using project-based rules. I don't believe there is any other backup application that has the equivalent of date-based rules that are more flexible than Retrospect's. I also don't believe that any backup application could have the equivalent of project-based rules that are more flexible than Retrospect's. I might be wrong in my second belief, because the advent of the GDPR's "right of erasure" has probably unleashed a storm of creativity among the developers of backup applications. However, given the wide variety of ways in which various commerce applications could store customer-identifying data—which is what the "right of erasure" is all about, I suspect that the GDPR solution for any backup application would have to have the same kind of flexibility that Retrospect's use of Rules in Grooming provides. And that kind of flexibility would require the same kind of minimal manual effort as an adaption for project-based Grooming. Please Private Message me with the name of the different product you plan to use for daily backup. I'd ask that you not post it on these Forums, because past experience has shown that the long-time head of Retrospect Technical Support "gets his knickers in a twist" when a Forums post mentions the name of a competing backup product. However I think he'd make an exception for backup products mentioned in this Knowledge Base article, which consist of one competitor that is much more expensive than Retrospect plus the free-but-limited Apple Time Machine. I just checked the manual for the much-more-expensive backup product, and it doesn't seem to have any capability that Retrospect Mac Rules don't have. As for Time Machine, we know its date-based filtering is more limited than Retrospect and its project-based filtering is essentially equivalent to Retrospect's.
    1 point
  19. Then, tbh, you need a better system for archiving that data. Like with backups (and I draw a distinction between archive and backup), you should be thinking "3-2-1" -- 3 copies on 2 different media with 1 offsite and, importantly, you should be rotating your archives on to new media more often you have been. High-resilience disk-based storage is relatively cheap and you should use that for your "primary" archive copy. Don't forget to check application versions etc -- you may be near the point where you'll need to re-write old data to new formats... I wouldn't know -- and I'm not sure I'd trust anything over Retrospect for recovering RS's proprietary format (tar tapes would be a different matter). Best to avoid any problems with "3-2-1", media rotation, regular checks that you can retrieve files, and so on.
    1 point
  20. Don't know about best, but what I'd try is: Rebuild to "tapeset1", starting with the first tape, expecting it to fail at the end of the tape as you've described Rebuild to "tapeset2", starting with the first tape, expecting it to fail... Take tape 1 out of the drive! Repair "tapeset2" and, when it says insert tape 1, mark tape 1 as missing and continue with tapes 2 and 3 You've now got the most data back that you can, albeit in two sets. You could then try and combine them by copying "tapeset1" to a new "diskset1", then "tapeset2" to that "diskset1" -- "diskset1" can then be moved to your newer machine for the conversion. Your choice as to whether "diskset1" is a File Set or Removable Media Set. You could, perhaps should, copy the two tape sets to two disk sets, convert them to the new format, then combine them -- it'll take longer but might be "safer". I'd also start to wonder about the chances of me ever needing to go back to data from 10+ years ago and whether it's worth all this extra work! That'd be a struggle between my innate laziness and my OCD, but you may have compliance issues to satisfy.
    1 point
  21. Thank you very much. That was the error. Funny that retrospect doesn't say the user which level of the hard disk it needs. Thank you so much.
    1 point
  22. oslomike, Was the Tape Backup Set that contains the "bad" tape originally written with the Exabyte drive? I'm guessing that this may be so if the Backup Set was created by v4 or v5; the timeline of Retrospect Mac releases at the bottom of this Retrospect History article versus the Wikipedia timeline for the release of AIT-2 seems to show that a Backup Set written up through 1999 couldn't have been written on your AIT-2 drive. Therefore, if you still have it lying around, I suggest you try re-reading the tapes in that Backup Set using your old Exabyte drive. I'm not an expert, but differences in mechanical skew between drives can make tapes written on one drive hard to read on another—especially for special characters such as end-of-tape markers. Let me tell you a tape story: In 1969 I was working as a programmer at ITT Data Services in Paramus NJ, and my boss asked me to write a program to read "gapless" tapes on the IBM S/360 DOS computer at our satellite Lakehurst office and copy them to ordinary "gapped" tapes. The "gapless" tapes were being written by the U.S. Navy's Lakehurst Naval Air Station (that's where the Hindenburg dirigible caught fire in 1937), using a tape drive attached to a radio-telemetry receiver that had no ability to store received data while an inter-block gap was being written. LNAS could read these "gapless" tapes using a Control Data minicomputer connected to a special tape drive that could somehow "stop in less than 2 inches and navigate backwards to before the stop", but the minicomputer had such a pitifully-small main memory (4K 12-bit words) that the LNAS engineers (testing top-secret aircraft; don't ask 🙄 ) couldn't do any real analysis on it. The engineers wanted ITT to copy such tapes onto "gapped" ones that could be read by an ordinary tape drive on one of ITT's 512KB OS/360 IBM mainframe computers in Paramus. I wrote a tricky copy program in S/360 DOS Assembler, and it worked successfully on a test tape. However it turned out that the LNAS tape drive attached to the radio-telemetry receiver had a skewed read-write head, and the Control Data minicomputer's tape drive read-write head had been skewed to match. ITT wasn't willing to skew one of its satellite-office IBM tape drives to match, so my program never got used in production. See an audio expert for an explanation of tape skew.
    1 point
  23. oslomike, My gut feeling, from having worked extensively with tapes many years ago on IBM mainframes which didn't yet have disk drives, is that you've got an unreadable end-of-data marker on the first tape Member of the input Backup Set. The computer operators—a separate profession in those days—used to have a utility program that could write an end-of-tape marker on a tape, but AFAIK we don't have such a program now. (Some folks may: In 1992 I had backed up my wife's Mac using a Maynard QIC tape drive before I erased her HDD, and the Maynstream backup program—the ancestor of BE—couldn't read the tape to restore it. I paid DriveSavers US$600 to recover the data from the tape, which they did; it'd now cost around US$2000.) If you've got the data from that input tape on the output Backup Set, IMHO what you should do is to run another Transfer to the same output Backup Set using only the remaining tape Members of the input Backup Set—starting with the 2nd one. A way to do that would be to mark the first tape Member of the input Backup Set as Missing, per the NOTE under "The Members Tab" starting at the bottom of the left-hand column on page 155 of the Retrospect Mac 6 User's Guide.
    1 point
  24. The actual recovery instructions are at the top of this thread. Read bottom-to-top for a complete understanding of this issue. -- x509. Robin, Thank you for this workaround. It looks very helpful and complete. I am going to copy/paste these instructions into a Word doc for reference. When do you expect that the Retrospect fix will be released? Version 17.5x? 17.6? November 29, 2020 16:49 PM – Robin – Director, WW Support Dear ---, Retrospect Agent Reply can be found below. Agent Response: Our engineers did some research into this issue, as part of an upcoming bug fix they are working on. They came up with the following directions to correct the system after the restart fails to boot the computer after the restore: Boot from the Windows installation media, when at the Install Windows screen hit Shift+F10 to bring up a command prompt. Run diskpart, run list disk, if only one disk shows run, select disk 0. If there is more than one disk, they should be able to hopefully verify based on disk size. If it is not disk 0 they would replace 0 with the number of the drive. 1. Run, list par, to verify that there are 4 partitions, Recovery, System, Reserved, Primary. 2. Run, list vol, the volume number they want to use in the next step will have a FAT32 file system and should be 99MB with System under info. 3. Run, select vol, (number identified from step 4), i.e. select vol 3 4. Run, assign letter=z and should see "Diskpart successfully assigned the drive letter". Type exit 5. Run mkdir Z:\EFI\Microsoft\Boot 6. Run xcopy /s C:\Windows\Boot\EFI\*.* Z:\EFI\Microsoft\Boot 7. Run z: then run cd EFI\Microsoft\Boot 8. Run the following commands a. bcdedit /createstore BCD b. bcdedit /store BCD /create {bootmgr} /d “Windows Boot Manager” c. bcdedit /store BCD /create /d “My Windows 10” /application osloader (they can change My Windows 10 to anything they want) 9. The last command run will return a GUID, example {D91FE7C2-605F-4A2B-B035-80A7C30979BF}, they will need to use this guid in the next step 10. Run the following commands a. bcdedit /store BCD /set {bootmgr} default {your_guid} (your_guid will be the guid mentioned in step 9) b. bcdedit /store BCD /set {bootmgr} path \EFI\Microsoft\Boot\bootmgfw.efi c. bcdedit /store BCD /set {bootmgr} displayorder {default} d. bcdedit /store BCD /set {default} device partition=c: e. bcdedit /store BCD /set {default} osdevice partition=c: f. bcdedit /store BCD /set {default} path \Windows\System32\winload.efi g. bcdedit /store BCD /set {default} systemroot \Windows h. exit 11. Reboot the machine. Please let us know if you have any additional questions, Robin Mayoff Director, WW Support Retrospect, Inc. ----------------------------------------- See your Case History for # 00076665 in your Customer Portal (sign in required): https://www.retrospect.com/support/case/5004U00000sShTs Verify your Support contract status: https://www.retrospect.com/upgrade?license=J376-4ZXD-E6HV-UTEZ ----------------------------------------- Additional Resources: * Knowledgebase - https://www.retrospect.com/kb * Forum - http://forums.retrospect.com * Training Videos - http://www.youtube.com/user/RetrospectInc ref:_00DU0Kyj8._5004UsShTs:ref November 28, 2020 01:58 AM I give up. and I'm very discouraged at this point. It would seem that volume restoration for Windows would be tested out extremely carefully before a release. I followed the instructions to first delete the entire contents of the target drive, and I still got the same error message list that I submitted previously. After playing around a bit, I tried to do a restore WITHOUT the system state. This restore failed because Retrospect refused to recognize the catalog file on a USB drive, even though it had recognized that same catalog file in previous restore attempts. What happened here??? Also, I had to to disconnect all my drives other than the ones directly involved in the restore because on two restore attempts, it _seemed_ that data on other drives got corrupted. As part of the setup for doing a restore, I was able to delete existing partitions, but not to actually reformat the drive. When I deleted partitions, my GPT formatted drive was converted to an MBR formatted drive, which would be a major pain to change back to GPT once Windows is installed. Another bug. Also, with every restore attempt, the existing Windows install was corrupted and would no longer boot, even for those operations that ended "incomplete." First I was re-installing Windows each time. Then I started to use Macrium Reflect Free to back up the existing install. All it does is partition backup and restore, but it does that quite well. After each failed restore operation, I had to restore that existing install with Macrium. I've spent way too much time on this issue, and it feels like I'm doing trouble-shooting for Retrospect. So when you do release fixes for these issues, then I will test them. I would be willing to be a beta tester for these features. My career was in software product management, so I'm very familiar with beta test programs, software quality assurance, etc. For a product suggestion, I suggest that the Restore Wizard work with drives other than C: November 28, 2020 01:58 AM , because WinPE assigns different letters to drives. I also suggest that Retrospect be able to do a volume restore to unused space on a drive, much as Microsoft does a Windows install to unused space. Please pass these suggestions along to engineering and the product manager. November 20, 2020 14:36 PM – Robin – Director, WW Support Dear ---, Retrospect Agent Reply can be found below. Agent Response: I asked my engineering team for feedback and they reported: It looks like this is the issue, X:\ProgramData\Retrospect\RtrExec.dir\Exec\State\ESP doesn't exist. The customer is sure that the system backed up was EFI? If so it sounds like they ran into this open bug, "Bug 9135 - RestoreESPData: statePath X:\ProgramData\Retrospect\RtrExec.dir\Exec\State\ESP doesn't exist, return kErrGeneric". The issue is that on some Windows 10 systems Retrospect gets a different error when attempting to check if the system is EFI that prevents Retrospect from backing the ESP. I am in the process of fixing this issue today but the fix is for backup and not restore Please let us know if you have any additional questions, Robin Mayoff Director, WW Support Retrospect, Inc. ----------------------------------------- See your Case History for # 00076665 in your Customer Portal (sign in required): https://www.retrospect.com/support/case/5004U00000sShTs Verify your Support contract status: https://www.retrospect.com/upgrade?license=J376-4ZXD-E6HV-UTEZ ----------------------------------------- Additional Resources: * Knowledgebase - https://www.retrospect.com/kb * Forum - http://forums.retrospect.com * Training Videos - http://www.youtube.com/user/RetrospectInc ref:_00DU0Kyj8._5004UsShTs:ref November 20, 2020 14:10 PM – Robin – Director, WW Support Dear ---, Retrospect Agent Reply can be found below. Agent Response: >I also tried to delete the Windows partitions and the various other partitions for a GPT drive. But I was unable to tell Retrospect to restore to unformatted space on the boot physical drive. What if I deleted the remaining partitions on that drive or tried to restore to a different SSD drive? When you boot from the recovery disk, you can use the menu option to configure drives. I typically suggest doing a complete disk reformat and then create one single partition for the entire disk. During the restore, the Microsoft ASR writer should automatically recreate the partitions to match what you had at the time of the backup. Please let us know if you have any additional questions, Robin Mayoff Director, WW Support Retrospect, Inc. ----------------------------------------- See your Case History for # 00076665 in your Customer Portal (sign in required): https://www.retrospect.com/support/case/5004U00000sShTs Verify your Support contract status: https://www.retrospect.com/upgrade?license=J376-4ZXD-E6HV-UTEZ ----------------------------------------- Additional Resources: * Knowledgebase - https://www.retrospect.com/kb * Forum - http://forums.retrospect.com * Training Videos - http://www.youtube.com/user/RetrospectInc ref:_00DU0Kyj8._5004UsShTs:ref November 20, 2020 06:30 AM Hi. I managed to figure how to get that snapshot you asked for. Attached. November 20, 2020 06:30 AM Attached 14.8 KB file: C drive backup option.PNG November 20, 2020 06:11 AM Costonel, I wasn't able to bring up a Properties menu item for the snapshot I wanted to restore from. I'm on Retrospect V17. I tried several different appraoches and once I selected a snapshot, Retrospect moved immediately to the next window in the restore process. Attached is a photo of the options I use when backing up the Windows volumes. I also tried to delete the Windows partitions and the various other partitions for a GPT drive. But I was unable to tell Retrospect to restore to unformatted space on the boot physical drive. What if I deleted the remaining partitions on that drive or tried to restore to a different SSD drive? November 20, 2020 06:11 AM Attached 13 KB file: C drive backup option.PNG November 19, 2020 10:11 AM – Retrospect – Attached 301 KB file: state win.jpg Dear ---, Retrospect Agent Reply can be found below. Agent Response: We assume your BIOS is set to UEFI if you have a GPT drive. When you selected the snapshot from which you restored, does the snapshot properties contain all the system state items like in the screenshot attached? Can you send us a photo of those items in your selected snapshot. Thank you for using Retrospect, Costinel The Retrospect Support Team --------------------------- Click the link below to update your support case. Note, the case is automatically closed if no response is received within 5 days). * Case # 00076665 - http://retrospect.com/support/case/5004U00000sShTs ref:_00DU0Kyj8._5004UsShTs:ref November 18, 2020 23:05 PM Unlike previous attempts, this time the restore operation did restore files as necessary, even though I didn't change anything about the way I tried to do the restore operatiion. However, there was one error, as noted in the Operations Log. As a result, the system would not reboot into Windows. The boot drive was so messed up that the BIOS prompted me to use a Boot Floppy. This time I did NOT get a message saying that the WinPE drive would be erased. For emergency purposes, any time I do any operations with the C: drive, I use a simple, but effective program that backs up and restores partitions, nothing more. It is called Macrium Reflect Free, and I don't consider it a replacement for Retrospect, but it does allow me to experiment safely, and recover from situations where Retrospect has somehow damaged the C: drive. November 18, 2020 23:05 PM Attached 78.1 KB file: Restore Operation 2020-11-18.zip November 17, 2020 12:02 PM – Retrospect – Dear ---, Thank you for contacting Retrospect support. Retrospect Agent Reply can be found below. Your Problem Description.: I can't get a Restore with System State to run to completion. The Restore operation starts but then terminates without actually restoring files. I disconnected all drives except my SSD (restore target), the HDD with the backup set sessions and a USB drive that has the the Retrospect catalog of backups. In addition, the WinPE Disaster Recovery USB stick is attached. Also, I got an odd message that the WinPE drive would be completely erased, just before the restore operation terminated. I don't understand why that would happen, since I clearly set up the restore to go to the SSD drive. Do you want me to upload some photos that I took with my phone? I really need to get this system restore done. My system runs Windows 10 Pro 64, version 20H2. It is homebuilt with AMD 3900X CPU/ASUS ROG X570 Strix-E motherboard, with 32 GB of RAM. The system has been running 100% stable for six months. The SSD is set up for UEFI/GPT format. Agent Response: We apologize for the inconvenience. The message about erasing WinPE is a cosmetic BUG you can ignore it. we assume you Restore locally Please provide us the log file to check it Reproduce the Restore locally to your SSD then Go to Reports>Operations Log and open the log file Go to File menu and select Export and export the log to your backup drive. You can zip it on your main computer and send it to us. Thank you for using Retrospect. Costinel The Retrospect Support Team Additional Resources: Have you tried our online self-service tools? * Knowledgebase - http://retrospect.com/kb * Forum - http://forums.retrospect.com * Training Videos - http://www.youtube.com/user/RetrospectInc/featured?hl=en ----------------------------------------- Click the link below to update your support case. (Note, the case is automatically closed if no response is received within 5 days). * Case # 00076665 - http://retrospect.com/support/case/5004U00000sShTs ------------------------------------------ ref:_00DU0Kyj8._5004UsShTs:ref November 17, 2020 04:52 AM I can't get a Restore with System State to run to completion. The Restore operation starts but then terminates without actually restoring files. I disconnected all drives except my SSD (restore target), the HDD with the backup set sessions and a USB drive that has the the Retrospect catalog of backups. In addition, the WinPE Disaster Recovery USB stick is attached. Also, I got an odd message that the WinPE drive would be completely erased, just before the restore operation terminated. I don't understand why that would happen, since I clearly set up the restore to go to the SSD drive. Do you want me to upload some photos that I took with my phone? I really need to get this system restore done. My system runs Windows 10 Pro 64, version 20H2. It is homebuilt with AMD 3900X CPU/ASUS ROG X570 Strix-E motherboard, with 32 GB of RAM. The system has been running 100% stable for six months. The SSD is set up for UEFI/GPT format.
    1 point
  25. Except, from the descriptions, it's a bug in 17.5.1 on Big Sur but not in 17.5.1 on Catalina. And Big Sur itself seems to be rather variable, with eg reports of general big slowdowns on recent Fusion-drive iMacs while being really nippy on old SSD MacBook Airs. I'd promised a test on my Big Sur Mini -- the wrinkle is that that's an M1 machine, throwing yet another confounding factor into the mix. So I'll try and find something else to test on, which'll let me speed trial the same setup on both Cat and Sur. The problem will be finding a spare bit of kit that isn't so old that backups are dog-slow in both tests!
    1 point
  26. It will not backup the files again.
    1 point
  27. Well, whadda know. In fact Retrospect 17 DOES support creating USB recovery media. It's just the bleeding documentation which is behind the times. Of course, even the software is not completely up to date. Starting with Windows update 1809, that is September, 2018, there is a supplementary download needed to create recovery media. And you would not know that unless you read some of the Microsoft documentation associated with the Windows Assessment and Deployment Toolkit (WADK). I'm writing this as Retrospect is creating recovery media. Wish me luck.
    1 point
  28. Prophoto, You are new here, and I don't think you will do very well with this comment. I'm a "home IT guy" with a Retrospect Desktop setup in use for over 10 years now. David is a prolific AND extremely helpful and knowledgeable contributor. I think you owe him a public apology. I can't express these thoughts strongly enough. Again, I think you owe him a public apology.
    1 point
  29. redleader and Nigel Smith, There surely can't be any Catalog updating in the run of a Copy script, because that script doesn't designate a Media Set as a destination—no Media Set means no designation of a Catalog. That's why I thought my test might run faster than the equivalent Recycle run of my Backup script. In fact its copying phase ran slower. Maybe cramming copies of multiple source files into a single .rdb file is faster than adding each copied file to the macOS HFS+ filesystem, but I'm not inclined to investigate it. There weren't any files in the destination folder. I had deleted all those that were copied there by a test run I killed after 5 minutes, when I noticed the script mistakenly specified Copy all files (which wouldn't require name comparison) instead of Copy only missing files—which redleader specifies. In any case, my test proves that redleader could get his backing up done faster with Backup scripts. He could also use the resultant Catalogs to do grooming as Nigel Smith suggested. I don't bother with grooming, since I must—because I've experienced multiple cases of water leaks from an apartment two floors above mine—swap a portable HDD containing complete-as-of-Friday-morning backups of all my drives off-site once a week. P.S.: On pages 120–121 of the Retrospect Mac 16 User's Guide, under item 6. there are 5 paragraphs following this single-sentence paragraph: that describe not only the pop-up that redleader shows he chose in the screenshot in this up-thread post, but each of the other pop-up options. Those 5 paragraphs have been deleted from page 110 of the Retrospect Mac 17 UG—evidently by the StorCentric Slasher (my name for him 🤣 ).
    1 point
  30. 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!
    1 point
  31. pwbimm, In Sources, select the "client" machine and click on the Options tab. Under Volumes on the dialog there's a dropdown labeled "Back Up:". Set that to Selected Sources, and check-mark the Macintosh HD you think you want to back up. Alternatively, set the dropdown to Startup Volume. Look in the Console at a Backup script while it's running to see if you're backing up the correct Macintosh HD. I encountered the same problem when I started to backup my MacBook Pro running macOS 10.12.6 Sierra using Retrospect Mac 14.6.0. Adding the MBP as a "client" defaulted to All Volumes in the dropdown, and one of the two volumes is a garbage-named volume which the Engine can't find. I submitted a Support Case about this, but Retrospect Tech Support replied that the garbage-named volume is Apple's fault.
    1 point
  32. I don't think you can turn off hardware compression. At least it's turned on by default and it's hard to turn off. Since the tapes hold 400GB of (native) data you already have compression on. Software compression is for disk media sets. The compressed capacity of the tapes depends on two things: How "compressable" the data is and how fast it reaches the tape drive. Many file types today is already compressed: Audio, video and images to start with. Then PDF files and word processing documents are often compressed. Files that are already compressed can't be compressed more. What is easiest to compress is pure text files. If data isn't fed fast enough to the tape drive, blank (useless) blocks are added to the tapes while waiting for more data. This is much better (for many reasons) than having to stop the tape motion, reverse the tape a bit and start the tape again when data has arrived. Many small files are slower than fewer large files (for the same amount of bytes).
    1 point
  33. Over the year, the same thing has had many names. Now (I think) it is called "progressive" backup. speedvsaccuracy.pdf
    1 point
×
×
  • Create New...