Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


lunadesign last won the day on July 5 2015

lunadesign had the most liked content!

Profile Information

  • Gender
    Not Telling

lunadesign's Achievements


Newbie (1/14)



  1. Neat....thanks for trying this out. My understanding is that ReFS implements many of the core filesystem APIs that NTFS does but doesn't implement some others. So it's possible that Retrospect "just works" without the Retrospect developers having to add any specific code for ReFS. The trick is whether or not Retrospect requires any of the NTFS features that are not implemented in ReFS. Perhaps the "what type of volume is this?" relies on one of those unimplemented features. I'd feel a lot better if Retrospect listed it in their support matrix since they do list 8 / 10 / 2012 and 2012 R2 in their OS support list.
  2. Does Retrospect support ReFS (introduced in Windows Server 2012 but also apparently usable in Win 8.x and Win 10)?
  3. I'm running Retrospect Desktop and I just got the following warning for the first time during a backup: Writer "ASR Writer" backup failed, error -3050 ( VSS reported an error). What does this mean and should I be concerned?
  4. Sorry for the delay in responding. I ran "chkdsk.exe /f D:" and it found no errors. The backup set that was causing the issues currently uses 2.4 TB and has 9,395 files. I've been using this backup set for nightly backups for over a year so the # of sessions may be part of the problem. However, its strange that it was working great and then suddenly stopped working and can't be recataloged. What's interesting is that I just ran my weekly backup sets. Both are at least a year old but get run only weekly. The 1st weekly set gets groomed every 2 months or so. It backs up a small number of huge files so the grooming operation is usually a few minutes long. This time it took 35 minutes although I didn't see any errors in the log. At this point, I was suspicious so I nuked this backup set and restarted it from scratch. The other weekly set backs up a more typical mix of files but it never gets groomed. It ran perfectly. The bottom line is that I still don't know what happened but am seeing a possible pattern - backup sets with lots of sessions that employ grooming. Any other ideas on how I get can resuscitate my nightly backup set? Maybe updating Retrospect to the latest 9.x release?
  5. Thanks again for your assistance....I really appreciate it. I tried what you suggested and had no problems setting up another backup set and backing up roughly 35 GB of data. I then went back to the problematic backup set and did the "forget-then-recreate" approach and it failed again exactly like before. Like before, the error count racks up errors at roughly the rate of 2-3 errors per second.
  6. Thanks for your help Scillonian. I had not tried the forget-then-recreate approach, so I just tried that but encountered the exact same problem. Unfortunately, I do not currently have any other backup sets on D. My other backup set is on a removable drive that I periodically bring onsite from an offsite location.
  7. I have a pretty simple setup. I have a single Windows 7 box that does all my backups. The C partition is an internal HDD that contains OS, apps and the Retrospect catalog files. It has about 78 GB free. (For comparison, the catalog file for this backup set is in the 4-6 GB range.) The D partition is an internal HDD that is only used for backup set RDB files. It has about 344 GB free. I typically do a groom operation when it gets down to about 50-80 GB.
  8. I'm using a slightly older version of Retrospect Professional (version on Windows 7. During a normal disk set backup the other day, I got a "Device trouble" "error -105 ( unexpected end of data)" error. I tried doing a recatalog, but Retrospect racks up a bunch more of these errors and doesn't get anywhere. I understand that this is usually due to one or more of the RDB files being corrupted. I saw the forum post about changing device logging to level 7 and tried doing that but didn't get much info. I ended up using the Sysinternals Process Monitor to watch which RDB files were being accessed when the errors are being generated. I discovered that the recatalog was stuck on the first RDB file so I stopped the recatalog, moved the RDB file out of the directory, and tried again. The recatalog then got stuck on the second RDB file, so I stopped the recatalog, moved that RDB file out of the directory, and tried again. It kept getting stuck so I ended up removing the first 20ish files and it still gets stuck. I have a hard time believing that all of my RDB files are corrupt so I'm wondering what else could be wrong. I've checked the Windows Event Viewer log and don't see any file system issues. I tried copying some files on the file system where the RDB files are stored and had no issues. Any ideas? Thanks in advance!
  9. Just a quick heads up that I've discovered that snapshot transfers work differently in 9.x. The key point is that if you have a lot of sessions, they take a *lot* longer. In my case, they are taking 20 to 40 times longer. (No, that's not a typo.) The Retrospect team is aware of this and is hoping to fix this in a future release. As much as I love the new block level incremental backups, I can't implement my backup strategy without snapshot transfers so I'm reverting to 8.5 (and abandoning my 9.x backup sets) until this gets fixed.
  10. I ended reaching out to Retrospect Support and got the following response: The entry in the log is debug logging you can ignore. Because the log says "Execution completed successfully", you are safe. It is a message that is not set to the proper debug logging level which is why is is showing at default logging. It is a benign message and can be ignored. It will be fixed in an update to version 9 which will be out later this year.
  11. I'm testing Retrospect Desktop 9.0.1. During a snapshot transfer, I saw this in the middle of the log entry: runDoRequest:thd 0xb04: wantCreate is default on search for 1-Offsite Set G, uniqID 0x4e2312d4 What does this mean? Should I be concerned? Here's the full log entry: Log for Script: Transfer Snapshots to Off Set G Date: 8/14/2014 + Executing Transfer Snapshots to Off Set G at 8/14/2014 4:46 PM To Backup Set Offsite Set G... - 8/14/2014 4:46:28 PM: Transferring from Local Set C - 8/14/2014 4:46:28 PM: Transferring from Local Set C - 8/14/2014 4:46:28 PM: Transferring from Local Set C runDoRequest:thd 0xb04: wantCreate is default on search for 1-Offsite Set G, uniqID 0x4e2312d4 8/14/2014 5:14:53 PM: Execution completed successfully Remaining: 1 files, zero KB Completed: 184546 files, 53.5 GB Performance: 1947.9 MB/minute Duration: 00:28:25 (00:00:18 idle/loading/preparing) - 8/14/2014 5:14:53 PM: Verifying Offsite Set G 8/14/2014 5:23:46 PM: Execution completed successfully Remaining: 1 files, zero KB Completed: 184549 files, 65.1 GB Performance: 7578.3 MB/minute Duration: 00:08:52 (00:00:05 idle/loading/preparing) 8/14/2014 5:23:57 PM: Script "Transfer Snapshots to Off Set G" completed successfully
  12. Is it safe to upgrade directly from 8.2 to 9.0.1 or should I first upgrade to 8.5 and then to 9.0.1? And will my 8.2 backup sets work "as is" or do I need to do any recatalogs? Thanks!
  13. I haven't upgraded to Retrospect 9 yet but was wondering about the performance implications of enabling Block Level Incremental Backup. I realize that using it could potentially reduce the amount of data to be backed up (which could speed things up). However, does enabling this feature require extra processing power / time (either on the server or client) to do all the comparisons? BTW, does anyone know what kind of checksum is being used for the block comparisons?
  • Create New...