Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. I'm home again, so I just had a chance to check SMART status on my backup drive. Clean.
  3. jhg

    Queueing Jobs Manually

    If I start Job A which uses BackupSet-1 and then attempt to start Job B, which also writes to BackupSet-1, Retrospect complains that the backup set is in use and refuses to queue the job to wait for the backup set to become available. However, if I edit Job B and add a one-time schedule entry to start 1 minute from now, while Job A is still running, Retrospect dutifully queues Job B and runs it when Job A finishes. This is probably a feature request. In the first situation, where I attempt to run a job for which a resource is currently in use, I would like for Retrospect to queue the job just the way it does when the job is started by the scheduler instead of manually.
  4. MrPete

    How to restore files on top of what's there?

    Sigh. Mark, thanks for confirming what I sensed. This really is a bug in Retrospect. I'm about to report it. Let's say you choose "Replace Corresponding Files" from the dropdown. My expectation: it will replace the corresponding files. The documentation is clear about this. Unfortunately, it doesn't work. Retrospect ASSUMES that the data content matches, if the metadata matches. Boo. I guarantee that the "already copied" files aren't the only ones... and in fact, if I prepare a *backup* of the bad data, it's going to copy way more than a few hundred files. Time to report this bug. ======== A few quick comments on Mark's other suggestions: Preserving Data: In my situation, I've already replicated the drive. Nothing will be lost. SpinRite: I know exactly how/why the drive was partially zero'd. (It was my mistake )... no need for SpinRite this time. (YES I highly recommend SpinRite... Look for Pete H here - https://web.archive.org/web/20040825043909/https://www.grc.com/sr/testimonials.htm Bit Rot and Drive Replacement: In reality, bit rot can happen on ANY drive. In no way does bit rot imply a drive that needs to be replaced! Just for example: Consumer SSD drives retain data "perfectly" for approximately one year (if you've not overwritten a sector) before bit rot begins to show. It's worse for enterprise SSD's (because they are focused on performance over data retention.) This is not exactly advertised by the industry. Dig into the latest research and you'll discover the reality..) NOTE: some mfg's MAY be compensating for this and taking care of it in firmware... but I have yet to see such workarounds documented. And YES I have been harmed by this. Consider: what is the one sector on a drive or partition that NEVER is overwritten?... (How to avoid this: regularly rewrite every sector of an SSD. I do it about 3-4 times a year. I could point you at the (very!) technical research work that underlies what I wrote above. I agree that it's more than a little surprising.
  5. Yesterday
  6. Mr. Pete, Until I read your guide, I thought I now know everything to do a Windows partition recovery. Now I realize that crucial pieces exist only in my mind, and that approach doesn't scale well with multiple systems or across time. I've printed out a copy (PDF)of your post, which I'm saving in the same folder as my Retrospect user guide. I'm sure that your post is still valuable, even though I am now on R 16. x509
  7. mbennett

    How to restore files on top of what's there?

    Pete, Yes you can do this. Setup your restore job under Manage Scripts. On the Destination Selection window, there's a list box at the top of the window "Retrieve Files & Folders". Click the down arrow and choose the option you want. If you can, you should restore all files to a new location. My advice, if this is at all possible, is to replace the drive and then restore. What you're doing is super risky as I'm sure you're aware. Make a Disaster Recovery disk to do this, and run it on the problem system. My further advice is to go to http://grc.com and purchase Spinrite and run it on your system first. If your drive isn't healthy and is repairable, Spinrite will do it. Your system must be able to run 'chkdsk /f' first before you use Spinrite. (I can't type the Cee-colon in that command, the stupid forum software keeps inserting a smiley face for some reason.) You should also have SMART turned on so you're warned if the drive is close to failure. Good luck, Mark
  8. You might find this post from last year helpful...
  9. I am surprised this is not an obvious functionality. Scenario: - Existing drive, good backups - For !@#$% reasons, a chunk of an NTFS partition was literally zero'd out at a low level - Result: files are all in place but I guarantee their contents have changed. Consider it bit rot on a massive scale What I need: - Restore essentially all backed-up files, ignoring the fact that the metadata matches perfectly - In other words, I want to do a restore-with-overwrite. - Important note: I do NOT want to simply restore the volume if at all possible, because there are many new/changed files not in the backup. I can't find a way to do this. What am I doing wrong? Mostly, it auto-deselects all the files that appear to already be there (matching in size and date stamps). Any ideas much appreciated. I'm about ready to do the obvious/pain-in-the-neck workaround... - Find all new files and copy elsewhere and/or - Delete all files that aren't new THANKS! Pete
  10. Last week
  11. I am out of town for a week so I will check Smart status when I return x509
  12. Earlier
  13. Could you go back to whatever version you were using before you "upgraded" to 16.1?
  14. Surface test only checks "usable" disk space -- it doesn't include bad sectors that have already been mapped out. So it's probable that the "missing" files were on a bad sector that has already been "fixed" by Windows. Possibly, given the numbers involved, a problem in whatever is NTFS's equivalent of the file allocation table. You can check by viewing the SMART data for the drive, which will tell you how many sectors have already been re-allocated.
  15. About 6 weeks ago I started getting -559 network connection timeout errors after about 2 hours while running my weekly "Sat. Backup" full backup of my MacBook Pro (the first of 3 drives plus a Favorite Folder backed up in that script). There had not been any change in any of my software or hardware, so I guessed that at least one of my two Netgear Gbps Ethernet switches was starting to feel its age. I replaced both switches with non-Netgear 100Mbps switches I had lying around, and the problem went away—without slowing anything down except (moderately) the MBP's Compare phase of "Sat. Backup". Since NewEgg was having a US$15 sale on TP-Link 8-port Gbps switches (Heavens to Betsy, my home LAN is becoming obsolete because I'm not upgrading it to 10Gbps ), I ordered a pair of them. Even though replacing both 100Mbps switches with the Netgear Gbps switches one at a time didn't cause the -559 problem to recur, a week ago Sunday I replaced both switches with the newly-arrived TP-Link Gbps switches. The -559 problem still didn't recur last Saturday, so Sunday night I went into experimental mode and Deleted-Added my MBP with Use Multicast. Both a pre-scheduled "sacrificial" "NoOp Sun.-Fri Backup" script and "real" "Sun.-Fri Backup" script failed with -530 errors when I booted my Mac Pro "backup server" machine after the time when they were scheduled to run. I therefore Deleted-Added my MBP with Add Source Directly, and have had no further problems. IMHO this experience proves that my -530 Bugs 1 and 2 are not caused by a "security improvement" that was made solely in Netgear's Gbps Ethernet switches. Because I started getting -530 Bug 1 immediately after I replaced the failed D-Link 100Mbps switch in my study with a Netgear Gbps switch on 30 January 2017, without any change in my then-current Verizon DSL "gateway" router, my guess is that the "security improvement" was made to several manufacturers' Gbps Ethernet switches. And no doubt there is a contributing factor of Retrospect's implementation of its Multicast feature failing to keep up with the "security improvement".
  16. Update. Surface test showed drive had zero surface defects. The Verify Media operation on my 2019 Media Library dataset just completed, after almost 3 hours. There were many errors. Here is a sample: Next step is to recreate the dataset from files, and then verify again. I also want to verify six other datasets, which I have started and then paused. Those operations will take another five hours in total. However, in about 15 minutes, we are leaving for a vacation, so I have to hibernate this system. I'll complete all this week after we get back,and I'll post an update. Again, appreciation to Lennart.
  17. So following Lennart's suggestion in message #2 of this thread Massive number of "bad backup set header" messages I started to verify all the datasets on my 2019 backup volume. Retrospect could not find any of them. 😱 But that was because I was trying to verify 2019 datasets on my 2018 backup volume. Here is what happened. I always use Drive G for the Retrospect backup volume. If I need to retrieve files from a different year, I install that drive into my system (via docking station), and then use Minitool Partition Wizard to change Drive G to that other year's backup volume. Works very well, but this time I forgot to switch Drive G back to my 2019 backup volume before doing the dataset verification. Ooops. 😅 x509
  18. Lennart, Thanks. I'm running a disk surface test right now. My backup drive is 6 TB, and the test will need another 8+ hours to complete. I'm going to let the computer run overnight.
  19. Yes, it could but not likely by itself. It looks like you have a hard disk problem, since some files can't be read properly. Test the hard drive, including a surface scan. Page 459, "Verifying Backup Set Media" http://download.retrospect.com/docs/win/v16/user_guide/Retrospect_Win_User_Guide-EN.pdf Maybe you can. Page 454 in the above user guide: "Recreating a Catalog"
  20. I just tried to retrieve some files from my 2019 Media Library dataset and got all these error messages in the logfile. The logfile was 1375 lines total, and the activity monitor shows 1358 errors, no warnings. I'm running Retrospect Pro 16.1.1.102 on Win 10 Pro 64. My backup drive is internal SATA 6G. What could have caused all these messages. Just the other day, I ran the built-in Windows "defrag" command, and it ran normally. Could this operation have screwed up the dataset? How can I test my other datasets? Can this dataset be repaired, or do I need to create a new 2019 Media Library backup dataset? Fortunately, I can retrieve the files I need from my 2018 backup volume, but these messages have really scared me.
  21. OK. The copy finished and I got around to testing the copy. I can navigate into the copied directory for a Verify, but when I select the data member, it goes straight back to wanting me to Choose Media again, without putting anything useful into the log. Also, very oddly, when the top level directory of the copy is called "NewRetro", I can navigate in the directories inside it, but if I rename it to "Retrospect" (the original name), I can no longer navigate inside it. Also, When the old copy is renamed from its original name "Retrospect", to "OldRetro", I can navigate into its directories, but a Verify of its members fails in the same way as the Verify of the copy. Looks like I'll need to set up new backups.
  22. DavidHertzberg

    .mkv files and backups in Retrospect v.16

    CherylB, Here's a Retrospect 8 Forum thread from early 2011 that discusses this problem. IIRC Retrospect Mac 9 wasn't released until late in 2011. A key question is whether your user's .mkv files have the .mkv extension on the name of the file. If not you've got a problem, unless you restrict what is scanned via Favorite Folders etc. as later posts in that thread suggest. BTW, this "Retrospect Mac bug reports" forum is no longer routinely looked at by anyone from Tech Support, so you might as well have posted your problem in the parent "Retrospect 9 or higher for Macintosh" forum. Besides, it seems the problem isn't a Retrospect bug so much as a Retrospect limitation—it can't tell the type of a file that doesn't have an extension on its name.
  23. I am running a ProactiveAI backup on a MacBook Pro (no parallels installed) and specifically selected in Rules: "User Files and Settings except movies and music." I started this backup at noon and it is backing up .mkv movie files! After waiting a few hours I stopped the backup because the user is leaving the office for the day. Is there another trick to tell Retrospect NOT to backup the .mkv files??
  24. Apologies for the long delay in updating this thread. Among other things, I have been very busy supervising a house extension. I must confess that I never noticed Lennart's reference above to antivirus software, but about two weeks later I found a suggestion in some other forum that made me suspect that Microsoft Windows Defender (which now seems to be called Windows Security) might be the cause of my problems. Within its Ransomware Protection settings there is an option called 'Controlled folder access'. I turned off that option on 29 July and my daily Retrospect backups have been running fine ever since! One strange byproduct of using the 'Controlled folder access' option is that I found my attempts to save a modified Word or Access file under a new name was rejected on the grounds that the file did not exist. Of course the file didn't exist. That error message made no sense at all. I can only assume that Microsoft introduced a bug into into its security software via a recent update.
  25. I tried doing a partial copy of one of the disk media sets, and it seemed to be accessible from Retrospect. I'm currently doing a full copy of both disk media sets. It's s.l.o.w. I'll let you know how it goes. Thanks for the suggestion. It's still no clearer why two long-functioning media sets decided to "disappear" from retrospect.
  26. You might still be carrying some cruft over from the "old" directory structure. Instead of what you did, copy (not move) the members from old to new directory, creating any required sub-directories by hand as you go. Set all permissions to the same as the newly-created top level Retrospect directory. Get Retrospect to "Rebuild" the media set, adding members as required, but make sure to save the new catalog in a different location so you don't overwrite the old one. That's quite a lot of work. But it could get you out of a hole if you need to keep the old sets available for restores -- you never said in the OP if Retrospect still had the read-access that restores require. If it does then I wouldn't bother, just move onto the new sets.
  27. OK, I tried making a new backup into a directory that Retrospect had newly created on the NAS, and it all worked just fine. I then renamed that directory to the name of the original backup top level directory and moved the backup set directories into it, but still no good. I think I'll abandon the old backup sets and create new ones. All a bit annoying.
  28. Doesn't need much. NASs usually use Windows ACLs for permission control, which don't directly translate to POSIX/OS X permissions. So it's always a "best approximation", can be tighter or looser than expected/intended, and can be interpreted in different ways by different programs (if they aren't using OS X's APIs). I'm not expecting my workround to work, but it's worth trying before you contact Support -- more data points will help them help you.
  29. Thanks for the suggestion, but from Retrospect>About: "Version 16.1.2 (102)". So no luck there. Nigel, thanks for your suggestion. I haven't had time to try it out yet, but I will. I may also try moving the existing backup members to another directory on the NAS, too. The NAS doesn't have much in the way of permission control. Only registering users with passwords, specifying the name of the directory subtrees that are exported to them and whether they have read or write permission. The NAS feature of the router seems to have been a bit of an "oh, look, there's room for Samba, so let's put it in" effort. It was removed a while back for space reasons, but there were enough user grumbles that they found space for it again.
  1. Load more activity
×