Jump to content

Leaderboard


Popular Content

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

  1. 3 points
    David, your condescending comments aren't needed here. Martin (and others, myself included) are frustrated at this slowness, and a little venting is not out of order. I don't understand why you feel the need to carry water for Dantz - if you don't have anything positive to contribute, you aren't required to post.
  2. 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?
  3. 2 points
    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!
  4. 2 points
    Wha is an "august Documentation Committee"? Sounds like fake news, if you ask me.
  5. 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.
  6. 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 !
  7. 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.
  8. 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.
  9. 1 point
    As to how the crashing bug report will be treated, read the fifth paragraph in this 2017 post. I have never had ASM, but Tech Support responds to my bug reports; for one bug I was given a test release with enhanced logging—although I didn't get personalized help.
  10. 1 point
    I'm backing up a couple of Macs and Retrospect seems to place an inordinate load on them. My Macbook Pro 17", for instance, is hyperventilating several hours per day even though I hardly use it. I had Crashplan until they cancelled the service, and even though they backed up every 15 minutes, it was totally inconspicious and effective. Retrospect is a steamroller compared to that. Admittedly, Retrospect backs up more files, but still. Every now and then backups went smoother, and that was when Instant Scan did its work (as verified in the logs), but most of the time Instant Scan simply bogs down the machines but doesn't actually work. I had a week-long exchange with Retrospect support about this, trying to figure out why Instant Scan is totally ineffective, but once they escalated, I was told Instant Scan is no more. Not that it's having problems, no, that it has been abandoned. Does that mean my Mac backups will continue to be so grossly overloading the machines? I'll quote verbatim the last message I did get from Retrospect below. To me it sounds like Retrospect on MacOS will forever remain a dog. (I should mention that Instant Scan already didn't work before I upgraded to 10.13 and APFS. I also assume Retrospect support meant to say "APFS" and not "AFP", which makes no sense in relation to 10.13. And makes no sense in any case on the local machine where Instant Scan works. Or maybe they actually did mean AFP and then I understand even less.) "Dear Martin, Retrospect Engineering Reply can be found below. Instant scan doesn't work on AFP, and most likely customer is using AFP if they are on OSX 10.13.We recommend disabling instant scan in ALL cases, we are disabling instant scan by default in future versions of Retrospect.Thank you for using Retrospect,The Retrospect Support Team "
  11. 1 point
    Just ran a backup on a 2014 iMac with wired Gb network (the Macbook Air is on wifi), and things are decidedly looking more useable than before Retrospect 16. The scanning took just 2 minutes 11 minutes or so and the entire process 20 minutes. Retrospect is back in the race now. I still can't make out if it's using instant scan or not, but with this speed it must be. /Martin + Normal backup using Razr at 2019-03-06, 18:19:20 (Activity Thread 1) 2019-03-06 18:19:20: Finished scanning backup set data files To Backup Set Razr... - 2019-03-06 18:19:20: Copying Macintosh HD on razr 2019-03-06 18:30:18: Found: 3796060 files, 863974 folders, 596.4 GB 2019-03-06 18:30:50: Finished matching 2019-03-06 18:32:18: Selector "Martin's machines" was used to select 3 681 740 files out of 3 796 060. 2019-03-06 18:32:30: Copying: 2330 files (3.9 GB) and 0 hard links 2019-03-06 18:35:25: Building Snapshot... 2019-03-06 18:35:25: Checking 863 974 folders for ACLs or extended attributes 2019-03-06 18:36:42: Finished copying 83 900 folders with ACLs or extended attributes 2019-03-06 18:36:55: Copying Snapshot: 2 files (1.2 GB) 2019-03-06 18:37:28: Snapshot stored, 1.2 GB 2019-03-06 18:37:28: Comparing Macintosh HD on razr *File "Macintosh HD/Users/mw/Pictures/Photos Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-shm": didn't compare *File "Macintosh HD/Users/mw/Pictures/Photos Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-wal": different data size (set: 32 992, vol: 45 352) *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.2019-03-05T19-37-16Z-00000": different data size (set: 360 448, vol: 368 640) *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.interim": different data size (set: 3 457, vol: 2 913) 2019-03-06 18:39:34: Execution completed successfully Completed: 2 330 files, 3.9 GB Performance: 1 595 MB/minute (1 332.2 copy, 2 003.9 compare) Duration: 00:20:13 (00:15:14 idle/loading/preparing)
  12. 1 point
    CherylB, I think you misunderstand what I've been saying in this thread. Instant Scan was not supported for APFS volumes as of May 2018, and I don't think that's going to change with Retrospect 16—because the macOS facility it depends on (called FSEvents) wasn't implemented in the same way for APFS as it was for HFS+. But, according to what Retrospect Tech Support told insont per this October 2018 post, "In our next full release of Retrospect the client scan APIs will be completely overhauled .... For local backups you can help speed things up by changing your current api settings .... Client API changes are being worked on and preliminary testing shows them being upwards of 10 times faster than they are currently." IMHO that means non-Instant Scan will be speeded up so much we won't miss Instant Scan. P.S.: I even have hopes that the speed of actual Mac Client data backup will increase with Retrospect 16, because of the changeover to 64-bit APIs. This February 2018 post by dittberner@dbr3.de says he got much faster backup of his Windows server files when he switched from Retrospect Mac to another application; he says further down the thread "The other product is not comparable (much more expensive and other functions)." dittberner@dbr3.de later PM'd me (signing it with his male first name) the name of the other client-server backup application; its developer was founded 18 years after Dantz Development Corp., and its 64-bit application—meaning it won't back up sources booted with anything earlier than OS X 10.8—"is ideal for businesses in the Media and Entertainment industry". IOW, my hypothesis in this February 2018 post in the dittberner@dbr3.de thread seems to be true only if you assume that the client-server application stays with the same set of APIs—rather than change its APIs from 32-bit to 64-bit. P.P.S.: What I predicted seems to have come to pass with the release of Retrospect Mac 16.0 on 5 March 2019. First, the cumulative Release Notes say for Engine "Improved: Scanning faster on APFS volumes" and for Client "Improved Mac: Client scanning faster on APFS volumes". Second, the cumulative Release Notes also say for Client "Alert Mac: EOL notice for Apple Mac OS X 10.3. 10.4, and 10.5 - See details"—where the details are the temporarily-hidden updated version of the Knowledge base article I linked to up-thread which says "Now that the transition to 64-bit macOS file system data structures is complete, Retrospect can no longer support 10.3, 10.4, and 10.5 with the Retrospect 6.3 Client and Retrospect 9.0 Client."
  13. 1 point
    insont and cgtyoder and CherylB, I just discovered, while writing a post discussing this problem (among others) in my authorized Retrospect thread on the Ars Technica Mac forum, that this Knowledge Base article has been temporarily hidden from view (I found it again through my link in a prior post in this thread) while having been updated to refer to Retrospect 16 as of 5 March 2019. I take this as confirmation that the engineers have now completed what must have been a substantial effort in changing a lot of 30-year-old code, which the developer(s) of younger backup applications such as the one insont mentioned have not had to go through. OK, IMHO you've now got a definite date (probably 6 March) when the non-Instant lengthy APFS scan problem will be—at least preliminarily—fixed. If you still want to vent, feel free to do so. If you want instead to file Support Cases, those would provide retroactive justification for Retrospect engineers having made the effort. But IMHO it's time to make good on "I promise to stop complaining once Retrospect shows any sign of at least trying to do something about this."
  14. 1 point
    bradp015 and Lennart_T, bradp015 can as of Retrospect Mac 14.6 do what he suggested in his OP, so long as he is simultaneously backing up a different Favorite Folder on the same drive in each script. He could divide his whole disk into Favorite Folders, which only apply to Retrospect, and have his two scripts back up the Favorite Folders in a different order. Alternatively bradp015 could do what Lennart_T suggests, with a Backup script and a Copy script. However he should be sure to assign the same Activity Thread, in the Summary tab for the Scripts, if he schedules the two scripts so that they could possibly overlap in execution. If he doesn't make sure to do that, the Copy script will ignore new or changed files that are being backed up—since it uses a Catalog File that is not updated for the Media Set until the end (barring any optional Comparing) of the Backup script run. P.S.: On 10 January 2017 I suggested in this Product Suggestions—Mac OS X thread that a modest enhancement to Retrospect would enable overlapping a Backup to a particular Media Set with a Copy Backup or Copy Media Set from that same Media Set as the source. That enhancement assumes that the Copy script would be scheduled at least a minute after the Backup script. On 2 April 2017 I converted that suggestion into Support Case ##54601 for a Feature Enhancement. That Support Case has been closed, with no evident action taken on it by Retrospect engineering since then. Considering that Retrospect 15 now enables multiple Activity Threads (Execution Units for Retrospect Windows) even for the Desktop Edition, IMHO Retrospect engineering should reconsider that enhancement for Retrospect 16.
  15. 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?
  16. 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.
  17. 1 point
    This might help: https://www.retrospect.com/en/support/kb/scanning_incomplete_1103
  18. 1 point
    Are you certain that you disabled the OneDrive Files on Demand feature for all users? If the Files on Demand feature is enabled the OneDrive folder becomes a Reparse Point instead of a real folder. To check if the OneDriver folders is a real folder or a Reparse Point use one of the following two command line methods. If PowerShell is set as the default terminal: Right click on Start and select Windows PowerShell (Admin) Once the PowerShell window has opened type cd C:\Users\henkv and press enter Type ls one* and press enter The will return something like: Mode LastWriteTime Length Name ---- ------------- ------ ---- dar--l 2018-05-08 19:15 OneDrive If the last character of the mode string is a "l" (lowercase L) then the Onedrive folder is a Reparse Point If Command Prompt is set as the default terminal: Right click on Start and select Command Prompt (Admin) Once the Command Prompt window has opened type cd C:\Users\henkv and press enter Type ls dir /al and press enter If the result is: 2018-05-08 19:15 <DIR> OneDrive then the OneDrive folder is a Reparse Point If the result is: File Not Found then the OneDrive folder is a real folder Even if exclude folder(s) and/or file(s) in a selector they are still scanned.
  19. 1 point
    Stu, After a certain amount of playing around, I got Retrospect Mac 5.1 running on my ex-wife's old HDD and seeing my old tape drive attached to her old Digital Audio G4 tower (which she gave me for storage about 13 years ago after she moved to her own apartment). I did a search on one of the Storage Sets, and found 4 files ending in .tiff. However when I tried to Restore them, it turned out that no DAT/DDS tape I have with that Storage Set name matches the date that the Catalog File is expecting. Before I recreate a Catalog File from one of those tapes, please describe step by step what you did.
  20. 1 point
    Sure, I am the Backup, I don't see why not. The only possible glitch I can see is that what you can now purchase is Retrospect Mac 15; Retrospect Mac 14 is obsolete. The cumulative Release Notes for Retrospect Mac 15.0 say "New: Support for LTO-8 tape devices", so the chances are the support for LTO4 devices is still there. In case it isn't, I imagine you can go through Retrospect Sales to get a license code for Retrospect Mac 14.6, which can still be downloaded. The one thing I would caution you about is that the Desktop Edition only supports a single non-autoloader tape drive. If your LTO4 tape drive is fancy-shmancy, you may have to purchase the Single Workstation 20 Client Edition—which is substantially more expensive. You can probably negotiate this with Retrospect Sales, with whom I have no connection other than as a customer.
  21. 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.
  22. 1 point
    Oh, and if it's any consolation, Retrospect for Windows doesn't do this any better (or worse) than the Mac versions. I can't speak to the Linux versions.
×