Jump to content

Search the Community

Showing results for tags 'verify'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Announcements, News and Resources
    • Latest News
  • Windows Products-Retrospect
    • Professional
    • Server, SBS and Multi Server
    • Device and Hardware Compatibility-Windows
    • Exchange Server Add-On Support
    • SQL Server Agent
    • Linux, Unix and Netware Clients
    • Express for Windows
    • Product Suggestions-Windows
  • Mac OS X Products-Retrospect
    • Retrospect 9 or higher for Macintosh
    • Retrospect 8 For Macintosh
    • Retrospect 6: Desktop, Workgroup and Server for Mac OS X
    • Device and Hardware Compatibility-Mac OS X
    • Linux Clients
    • Product Suggestions-Mac OS X
  • Macintosh OS 9 and Earlier-Retrospect
    • Express, Desktop, Workgroup and Server for Pre-OS X
    • Device and Hardware Compatibility Pre OS X
  • General Discussion-Retrospect
    • Networking and Clients
    • Strategy, Scripts and General Use
    • Retrospect iPhone App
  • Retrospect 8.x for Mac
  • Retrospect 6.1 for Mac
  • Retrospect 7.7 for Windows
  • Retrospect 7.6 for Windows
  • Retrospect Express
  • General Discussion


There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 11 results

  1. Hi, I've just rebuilt my catalog for a media set to be restored. I'd like to know that the files are ok as they been transferred over different drives. I know I can verify the media set to check this. In order to save time, if I just went ahead and did the restore, would that be doing a verify anyway? Thanks
  2. 63bda858-5080-4ac5-a935-a2f1399479d1

    What happens when, in the verifying phase, errors are encountered?

    If, after having done a backup, some errors show up in the verifying phase I would expect Retrospect to take note of the files or part of files (if using the block level incremental system) that were not correctly done and mark them so they will be included in the next backup. But, when I see many errors, I restart the job and usually no file (nor a part of one) are backuped again. Can I be sure that the data is already backuped correctly?. My system uses a Retrospect Professional for Windows version 10.5 backuping to DVDs. Regards Agustín
  3. Hello, I was running a backup onto a NAS which got stuck half way through the 'compare' stage. 1) Am I correct in understanding that 'Verify' on the media set in question will check the media set against the MD5 digests of the original source files which were made during backup? 2) If the MD5 wasn't created for comparison will I be told in the log? The manual says the file will be checked if it can be read if it can't be compared, but it would be nice to know. I'm essentially trying to avoid repeating a rather long backup which got stuck on the compare stage and would like to know if the 'Verify' is doing the compare for me? Thanks
  4. Hi there, I can't verify my media set, which has one member marked as lost. During backup one of the tapes gone bad, so I trashed it, marked as lost in media set and restarted the backup. Now, I want to verify this set - and I can't, because Retrospect asks for member which is marked as lost and I don't have it. What is the purpose of this option then? How can I verify if my set is readable? Best, W.
  5. A good piece of SW behaves correctly. A really great piece of SW behaves correctly even in the face of errors, and provides useful information when things go wrong. Retrospect 10.5 is not yet great. I have an occasional problem with my external firewire disks. I dont know where the errors originate, but they are "sticky", in that they are not intermittent once they appear. I have taken to running a "verify" script regularly on the media sets to ensure that the underlying HW is functioning correctly. These errors usually appear in clusters, affecting multiple media sets in a burst, and then staying "stable" between occurrences. In this case, out of 14 media sets, errors appeared on 7 of them. 6 of them are of the form: (blah blah) !Media Set format inconsistency (2 at 19357344) !Media Set format inconsistency (2 at 19971744) !Media Set format inconsistency (2 at 20586144) !Media Set format inconsistency (2 at 21200544) !Media Set format inconsistency (2 at 21814944) !Media Set format inconsistency (2 at 22429344) !Media Set format inconsistency (2 at 23043744) !Media Set format inconsistency (2 at 23658144) !Media Set format inconsistency (2 at 24272544) !Media Set format inconsistency (2 at 24886944) !Media Set format inconsistency (2 at 25501344) !Media Set format inconsistency (2 at 26115744) !Media Set format inconsistency (2 at 26132288) Remaining: 550 files, 0 B Completed: 3770 files, 34.6 GB Note that there are 550 files "remaining", and the 3770 is less than the number expected (by 550 files). The other type of error is: - 12/14/14 10:30:50 AM: Verifying v9_Virtue2 !Generated MD5 digest for file "/Volumes/VirtueHD/private/var/servermgrd/sessions/root@4B101fgg23MYmjL4Hhq9pNXY9pN1Idb5-admin" does not match stored MD5 digest. Completed: 467630 files, 29.3 GB Performance: 3,860.5 MB/minute Duration: 00:08:08 (00:00:22 idle/loading/preparing) These "MD5" errors seem to be rarer. I presume that these errors are some sort of data transfer problem with the disk, because when I read the disks in raw mode (or copy the files) no errors are detected in the disk operations. For some reason, data appears to have been lost in the transfer of the data from memory to the disk. Given the (lack of) data protection in the data path in essentially "consumer" HW, this is not so surprising. -- What is surprising is that the VERIFY operation detects errors, and a media set COPY runs WITHOUT error. What I have done (several times now) is copy the media set to another, and then copy it back. When I do this, I get the expected number of files reported by the verify, but *no errors*. Something is not right. 1. What does retrospect do with those missing 550 files if I try to restore from that media set? I have never seen an error reported from a restore saying it tried to restore a file and it was "unavailable". 2. Why does verify detect errors that copy ignores? (can't see?) Retrospect exists to protect my data. It needs to be explicit with me about what it fails to backup/preserve/restore. What's up with this? Is it different in retro 11.x?
  6. I recently have taken to running a "verify" on all my backup sets on a schedule, so I get some notification when the HW starts having trouble reading the media. On the most recent rotation, I see this: - 5/11/14 2:58:58 PM: Verifying v9_iCompute_last !Generated MD5 digest for file "Quantum18G/Household/Parties/dot75party.sitx" does not match stored MD5 digest. Remaining: 1 files, 0 B Completed: 508006 files, 57.8 GB Performance: 5,651.9 MB/minute Duration: 00:11:05 (00:00:36 idle/loading/preparing) What does it mean? When I restore from this set, I see this: + Restore using aRestoreTest at 5/13/14 (Activity Thread 1) To volume z-junk... - 5/13/14 3:54:08 PM: Restoring from v9_iCompute_last, Snapshot Joy, 4/28/14 4:22:15 AM !An error occurred during the verification step. The MD5 digest for the file "Quantum18G/Household/Parties/dot75party.sitx" did not match, error -1129 ( MD5 digest mismatch) 5/13/14 3:58:21 PM: 1 execution errors Completed: 31118 files, 9.2 GB Performance: 2,370.9 MB/minute Duration: 00:04:13 (00:00:13 idle/loading/preparing) There is a clearly an error of some type. I can't re-do the backup, since this was copied over from another set, and the original backup source has changed. Is there a way to "fix" this?It looks like I have one file that somehow has a bad/missing checksum. Is this because the copy operation from the other backup set dropped a bit? Is it a Retro bug? Inquiring minds want to know.
  7. I hit a hang at some point since the 26th of January. I saw the engine busy doing a scripted verify of all my sets on disk yesterday (It appeared to be running, from the flashing lights on the external disk(s).) Unfortunately, it was still "running" today, with the Retro engine at 100% CPU (one CPU @ 100%), and no lights flashing. There were two scripts showing "busy" in the Retro console. I tried to stop the two activities, and tried to stop the engine the "normal" way through the CP. I had to force quit the engine to free it. I snapped the screen with the two activities, and also the activities after engine restart. Note that the two activities that were "done" have vanished - no evidence that they happened. I include screen snaps of the two activities with both summary and log, and also a screen snap of the console after recovery. THe sample, as taken by the Activity Monitor while the engine was hung. This is a bug. Retro was "stuck" for almost a week. (Retro engine 10.5.145, Mac OS X 10.8.5 - Console retro 10.5.145, on Mac OS X 10.6.8) Sample_RetroEngine.txt
  8. when a member of a mediaset is marked as lost. Running verification on that set will stop with an error that the lost member is not found. Obviously it is not expected that the lost members are checked becausewe know they are not to be found... See also this post for a few othere whoa re seeing the same issues. http://forums.retrospect.com/index.php?/topic/148086-how-to-verify-one-media-member/
  9. I think the status displays are confusing for scripted verification in this version of Retrospect. In 10.5.0 the Detail and List view windows show: Summary shows a source and destination that don't make sense - a source and a destination in a verify? Details in the script accurately show multiple execution schedules for DIFFERENT sources List View shows source and destinations. On a Verify? Destination might be the catalog file, but this simply doesn't make sense.
  10. I have a limit of 2 active tasks in my engine (10.2.0 (221)) and I had two busy recently, and tried to verify a media set via the "verify" button on the media set pane. The media set went "busy", and the verify didn't happen. I don't think the media set is going to get un-busy unless I restart the engine. I'll wait for idle and do that. Bug. It should refuse the request, not permanently busy the media set.
  11. I ran an experiment (what and why is not important here) where I copied a backup set, and got an error. + Executing copy_set at 3/13/13 (Activity Thread 2) To Backup Set atrash... - 3/13/13 12:01:40 AM: Transferring from v9_daily_mercy_last 3/13/13 12:42:27 AM: Execution completed successfully Completed: 503 files, 59.2 GB Performance: 1,559.8 MB/minute Duration: 00:40:46 (00:01:52 idle/loading/preparing) - 3/13/13 12:42:27 AM: Verifying atrash !Generated MD5 digest for file "/Volumes/backup/d.root.130212.gz" does not match stored MD5 digest. 3/13/13 12:58:45 AM: 1 execution errors Remaining: 1 files, 0 B Completed: 502 files, 59.2 GB Performance: 3,887.5 MB/minute Duration: 00:16:18 (00:00:42 idle/loading/preparing) I then ran a verify on the source set, and the verify came through clean. I then turned on "verify entire media set" on a verify script, and it came through clean. I then ran the copy again, to see if the MD5 error was a transient of some kind. Nope. What does "verify" do, if not check things like the MD5 digests? What does "verify entire media set" do? I'm not sure, but I think there is a bug in here somewhere.