Jump to content

lunadesign

Members
  • Posts

    61
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by lunadesign

  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 9.5.3.103 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 9.5.0.140) 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?
  14. Thanks! And what if there are other corrupt RDB files? Will the recatalog operation get stuck or will it be smart enough to skip any other bad RDB files? And will Retrospect re-backup any of the files that were lost in the bad RDB file?
  15. I have a friend with an older system that's still using Retrospect Professional 7.6.123. It appears he accidentally corrupted at least one of the RDB files in his local disk backup set (only has 1 member) by forcefully shutting down Retrospect a few days ago when it seemed to be hung. The nightly local backups continued to work on subsequent nights but when he tried to do his weekly snapshot transfer, it failed with Retrospect re-asking for the backup set media for the local backup (the source in the snapshot transfer). I ran "Verify Media" on the local set and near the end of the session, it started re-asking for the backup media (just like above). When I clicked "Choices" and then "Browse", it became clear that it was looking for a certain RDB file. The file is still on the disk but when I select it, Retrospect says "This file is corrupted or does not belong to this Backup Set". The file's timestamp is pretty close to when the forceful shutdown happened so I'm not surprised this file is corrupted. However, I don't see any option to skip this file (and thus abandoning any data within it) so I'm not sure what to do. It's also possible that at least one other RDB file written around the same time is also corrupted but I don't know how to get past this file to check the rest. Should I delete the corrupt RDB file and recatalog? Will recatalog be smart enough to skip any other bad RDB files? Or should I delete the backup sessions from that day in the hopes that it prunes out the bad RDB files? In any of these cases, will Retrospect be smart enough to re-backup the files that were in the corrupt RDB file (assuming they didn't subsequently change and get backed up on a later date)? Thanks in advance!
  16. arachnaut - Thanks for the info. Is it still going well for you? I'm tempted to take the plunge this weekend. Does anyone else have any experience with the 8.1 Pre-Release?
  17. I've been on 8.0 for over a month and get the "Assertion failure at grx.cpp-1089" crash on roughly every other Groom operation. I hear the 8.1 pre-release (see this Knowledge Base post for details) fixes this and some other items but am nervous about using a pre-release version. I've also heard the official 8.1 release isn't targeted until end of quarter but can't wait that long with all the catalog rebuilds I'm having to do to recover from Groom crashes. Question: For those of you that have installed the 8.1 pre-release, how is it going? Is it better / more stable than 8.0?
  18. I got some interesting backup errors last night for the first time with Retrospect 8 Professional on Windows. First, a Windows XP client was being backed up when that job failed with "Trouble reading files, error -557 (transaction already complete)". The next backup job, a local backup of the system itself (the one where Retrospect Professional is installed) failed with 11,803 errors. Most of them are "can't read, error -1101 (file/directory not found)" or "can't read security inforamtion, error -1101 (file/directory not found)". What should I do?
  19. I was just about to upgrade from Retrospect 7.6 to 7.7 and see that Retrospect 8 is now out. Is it possible to upgrade directly from 7.6 to 8 while retaining my backup data and configurations? Or are there special steps I need to follow? Thanks in advance!
  20. Hi all, I've been running Retrospect 7.6.123 Professional successfully for many years but hit a very strange glitch last night. I was backing up a Windows Vista client over the network to a disk backup set when Retrospect got hung (and started chewing 100% CPU) during the Building Snapshot phase. I got an e-mail notification that says "Can't back up registry, error -519 (network communication failed)". When I got into the office hours later, the CPU was still at 100%. I couldn't stop the backup job so I ended up having to kill Retrospect via Task Manager. Question: Is there anything I need to do to make sure the disk backup set (or Retrospect's configuration) is okay before proceeding with my regular backup schedule? Thanks in advance!
  21. For what its worth, I have the "Match only files in same location" option turned on. I always presumed that by "location" they meant the combination of backup client, full file system path and filename. Its not clear to me how disk/partition serial ID's and geometries/sizes come into play in this logic. Does anyone have any info on this?
  22. I'd love to hear how your next backup goes....please keep me posted. I thought about the remove and re-add volume thing but its not clear to me if that would affect Retrospect's determination of whether or not the current partitions are equivalent to the ones on the old drive (ie, so it wont re-backup files that haven't changed).
  23. I recently replaced a hard drive in one of my backup clients with a larger one. I used Ghost Solution Suite 2.5 to transfer the data to the new drive. Although the partition sizes grew, the data's still the same. When I go to backup the client, Retrospect fails with error -1102 (drive missing/unavailable). If I change the partition serial #'s on the new drive to match the ones on the old drive, will this fix the Retrospect error? Or is Retrospect looking at partition sizes, drive geometry, etc? Ideally, I'd like Retrospect to continue doing incremental backups as if it didn't know about the drive change. I don't want it to do a full backup when most of the data on the client hasn't changed.
×
×
  • Create New...