Jump to content

Don Lee

Members
  • Content count

    564
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by Don Lee

  1. I tested this scenario with version 11.5.3, and it still does not work. I created a folder on the server called "•testme" and another called "testme2". The former yields an error when I create a media set. The latter works. screen shot enclosed.
  2. I just upgraded to retro 11.5.3 (103). I have tried several media set copies, with and without an initial recycle of the target media set. Good news - the media set seems to copy the data reliably. More good news - there seems to be no variation in behavior from run to run, and media set to media set. Even more good news - it's fast! The slightly bad news - The "verify" pass is speed-of-light fast. Dig the log below. Given that it takes *zero* seconds, I'm betting that the verify is not being done. I get this "fast verify" *only* when I do an initial recycle on the target media set. Note also that the performance of the script is *not* reported when the verify is "fast". + Executing acopy 3 at 12/24/14 9:35:12 PM (Activity Thread 2) To Backup Set atrash3-3... 12/24/14 9:35:13 PM: Recycle backup: The Backup Set was reset - 12/24/14 9:35:13 PM: Transferring from v9_daily_eims 12/24/14 10:08:34 PM: Execution completed successfully Completed: 6,832 files, 108.9 GB Performance: 3,441.2 MB/minute Duration: 00:33:21 (00:00:55 idle/loading/preparing) - 12/24/14 10:08:34 PM: Verifying atrash3-3 12/24/14 10:08:34 PM: Execution completed successfully 12/24/14 10:08:34 PM: Script "acopy 3" completed successfully Not perfect yet, but this is much, much better. Thanks.
  3. Excellent. I'm itching to try it. Thank you.
  4. I am setting up a test machine as an upgraded version of another, production machine. I wanted to restore a part of its filesystem with the current, production data on the production machine. I started a restore from the production media set (v9_icompute) to the "favorite" before midnight. While that restore was running, a normal, incremental backup ran to the same media set. The restore and the backup were running at the same time. The restore failed with this message: + Executing Restore Assistant - 12/18/14 11:04 PM at 12/18/14 (Activity Thread 1) 12/18/14 11:09:29 PM: Connected to Hope-temp To volume EIMS3 on Hope-temp... - 12/18/14 11:09:29 PM: Restoring from v9_daily_eims, Snapshot Hope, 12/18/14 12:02:39 AM State information not restored, can't access Snapshot 12/19/14 4:37:18 AM: 1 execution errors Completed: 2303 files, 8.4 GB Performance: 26.1 MB/minute Duration: 05:27:49 (00:00:16 idle/loading/preparing) It looks like the backup created a new snapshot, and "hid" the one that was being used by the restore, and at the end of the restore, it went to set permissions, and it was… gone! This seems to me a bug. Retro should not allow the restore and backup to run concurrently if it does not work (reliably). Retro 10.5 engine on Mac OS X 10.8.5 Client Mac OS X 10.8.5, retro client 10.5.0.145
  5. FWIW - Something I did not mention is that I accessed this mini's disk (with 10.10 on it) by putting the mini in target disk mode and connecting it to my retro server.
  6. I just bought a Mini with Mac OS X 10.10 on it, and wanted to back up the disk image before I blew it away, and retro barfed on me: *File "/Volumes/MacOSX/usr/share/terminfo/68/h-100bw": can't read, error -1100 ( invalid handle) *File "/Volumes/MacOSX/usr/share/terminfo/68/h100": can't read, error -1100 ( invalid handle) *File "/Volumes/MacOSX/usr/share/terminfo/68/h100bw": can't read, error -1100 ( invalid handle) *File "/Volumes/MacOSX/usr/share/terminfo/68/h19": can't read, error -1100 ( invalid handle) *File "/Volumes/MacOSX/usr/share/terminfo/68/h19-a": can't read, error -1100 ( invalid handle) *File "/Volumes/MacOSX/usr/share/terminfo/68/h19-b": can't read, error -1100 ( invalid handle) I got 98000 of these errors. Is there something in the 10.10 filesystems that retro 10.5 can't deal with? I see "full support" for 10.10 appearing in retro 11. Is this the problem that requires increased supprt?
  7. I have seen similar behavior in Retro 10, but only the proactive backups stop running. (scheduled backup scripts continue to run), and a reboot is unnecessary. Restarting the engine is sufficient. This is also fairly rare. If I could figure out what triggers it, I would post the scenario. It appears to me that it does not happen when Retro is "just running". It seems to be triggered when I am re-arranging media sets, adding scripts, etc.
  8. I restored the file with the MD5 error on the copied media set. The resultant (zero length) file is named: "root@2hN0vGB2QJo8yf6GQrNial5nb98a404Z-admin" The original on the media set, according to the log, is: "root@4B101fgg23MYmjL4Hhq9pNXY9pN1Idb5-admin" The full path of the file can be seen in the log excerpt above. The log of the restore shows no errors: + Executing Restore Assistant - 12/14/14 9:44 PM at 12/14/14 (Activity Thread 1) 12/14/14 9:48:08 PM: Connected to Witsend To volume TEMP_RETRO on Witsend... - 12/14/14 9:48:08 PM: Restoring from a_v9_virtue2, Snapshot /Volumes/VirtueHD, 12/8/14 2:15:48 AM 12/14/14 9:48:21 PM: Execution completed successfully Completed: 33 files, 18 KB Performance: 0.2 MB/minute Duration: 00:00:13 (00:00:08 idle/loading/preparing)
  9. 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?
  10. Another anomaly of note: The MD5 error that I am seeing shows the file with the MD5 error being copied to the destination media set. (!) I copied original -> copy, recycled "original", and then copied copy -> original. The same file showed the MD5 error on the copy in each direction. What does this mean? I have to conclude that if the MD5 digest does NOT match, then either the digest, or the data is corrupted. If the file is corrupted, I probably don't want it. I want to know about losing it, but I probably don't want it copied to the destination media set. If the file is still on the source, I want retro to toss it and re-copy it to the media set on the next backup. If I restore from this set, does retro tell me that the data is bad? (I'll try it)
  11. I can see the contrast when I copy a media set with an MD5 error: + Executing acopy 2.5 at 12/14/14 (Activity Thread 2) To Backup Set a_v9_virtue2... - 12/14/14 2:58:15 PM: Transferring from v9_Virtue2 12/14/14 3:13:08 PM: Execution completed successfully Completed: 467476 files, 28.7 GB Performance: 2,026.7 MB/minute Duration: 00:14:53 (00:00:22 idle/loading/preparing) - 12/14/14 3:13:08 PM: Verifying a_v9_virtue2 !Generated MD5 digest for file "/Volumes/VirtueHD/private/var/servermgrd/sessions/root@4B101fgg23MYmjL4Hhq9pNXY9pN1Idb5-admin" does not match stored MD5 digest. 12/14/14 3:20:45 PM: 1 execution errors Remaining: 1 files, 3.2 GB Completed: 467475 files, 28.7 GB Performance: 3,866.8 MB/minute Duration: 00:07:36 Judging from the file count and the error, retro copies the (bad?) file, and detects the MD5 error in the verify pass. When I copy these media set copies BACK to the originals, the copy operation only copies the number of files reported for the forward copy with the error. (If 500 files were missing, 500 fewer files are copied back, and no errors are reported) I have not attempted to restore from these "reduced" media sets, but I will do a backup, and expect that the missing 550 files will be re-added.
  12. Incidentally, the "10.6" is Mac OS X 10.6.8 on the client. The server/engine is running on Mac OS X 10.8.5.
  13. I had some trouble on a client machine yesterday, and it appears to continue. The notification email is failing, and the log is complaining, but I have no idea what this means: 1/13/14 10:06:58 PM: Execution completed successfully Completed: 367 files, 246.8 MB Performance: 592.2 MB/minute (448.6 copy, 925.4 compare) Duration: 00:03:08 (00:02:18 idle/loading/preparing) UAllowSystemSleepAgain: IOPMAssertionRelease failed, err = -536870199 E-mail notification failed: error -530 ( backup client not found) E-mail notification failed: error -530 ( backup client not found) Exit at 1/13/14 11:43:18 PM E-mail notification failed: error -530 ( backup client not found) + Retrospect version 10.5.0.145 Launched at 1/13/14 11:44:33 PM E-mail notification failed: error -530 ( backup client not found) Why on earth does not finding "the client" disrupt outgoing SMTP? (Mac OS X 10.6, Retro 10.5.145)
  14. I've seen this up to and including v 10.5. It was the pro-active scripts that stopped running. I've never seen the "scheduled" scripts stop. (AFAIK) In my experience, pause/resume was not sufficient. I had to stop and restart the engine.
  15. I ran into a problem backing up to a disk data set ("Users" on a FW drive) and needed to make the member "bigger". This was in the middle of a backup operation, and I didn't want to kill it, so I wanted to just edit the size of the existing member. Retro would not let me edit the single member in the set, but it would let me add another member, so I added a second member. I ended up with 2 members. One was limited to 186 GB, the other to 44 GB. I ran into a problem the next day with the backups, with multiple attempts to back up to this set, and each try I got: - 11/29/14 9:35:24 PM: Copying Databases !Catalog File out of sync with Media Set "Users". 11/29/14 9:35:59 PM: Execution incomplete I tried to "repair" the dataset, and it still did not work - same error. I tried the repair several times. The repair behaved badly, too. I could not get the "add member" dialog to show me the "1-users" and "2-users" members. It would only show me one "member" called "Users". Despite succesful "repairs", the subsequent attempts at backup all failed the same way. I ended up doing a media set copy to a temp media set, with the intention of copying the data back to "Users". When I did a recycle on "Users", I noted that the two members had the same size - 44 Gb. I enclose a screenshot, FWIW. I am now copying the data back to "Users". I'm confident that the recycled media set with one member will behave. Looks like a bug (or two) to me, but I don't know if I could reproduce it, tho. (sorry about the formatting - the forum doesn't seem to let me format the post)
  16. In 10.5 and previous, I could specify which "thread" to use for scripts. In 11.5, every time I select a specific thread, and hit "save" the thread is reset to "any thread". Is this broken, or has this capability been removed? I use it to ensure that certain operations run sequentially.
  17. The privacy setting should have nothing to do with the location of the *media sets* on the server. If it does, it's busted.
  18. The problem is not only back, it's worse. Not only do I get stunted copies when I recycle source/target, I can't get a good copy at all. See this thread: http://forums.retrospect.com/index.php?/topic/151499-copy-media-set-does-not-copy-old-backups/
  19. I can't live with this. I'm going back to v 10.5 until this problem is fixed. I upgraded to v11 to fix problems with media set copies, and it's worse, not better.
  20. Version 11.5.2.107 is just as bad with the resultant media sets, and the log files imply that only a fraction of the data was copied and/or verified. This is worse than 10.5. As an example, I did a media set copy of v9_icompute to v9_icompute_last. v9_icompute had 722424 files, and 90+ GB of data. The resulting copy contained 719786 files and 79 GB of data according to the Media Set display "summary" panel. However, the log from the copy contained this - only 5.3 GB copied?!?!?: ---- + Executing acopy at 11/8/14 8:58:46 PM (Activity Thread 1) To Backup Set v9_iCompute_last... - 11/8/14 8:58:46 PM: Transferring from v9_iCompute LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 11/8/14 9:10:48 PM: Execution completed successfully Completed: 16,077 files, 5.3 GB Performance: 507.8 MB/minute Duration: 00:12:02 (00:01:19 idle/loading/preparing) - 11/8/14 9:10:48 PM: Verifying v9_iCompute_last 11/8/14 9:12:15 PM: Execution completed successfully Completed: 16,077 files, 5.3 GB Performance: 4,180.3 MB/minute Duration: 00:01:26 (00:00:08 idle/loading/preparing) 11/8/14 9:12:18 PM: Script "acopy" completed successfully ----
  21. Busted. After the rebuild of a media set with 703,709 files, and 24 backups (according to the "summary" panel on the media set), I can only see five backups in the "backups" panel, and when I click "retrieve", there is nothing there. I'm going to 11.5.2.107 now to see if it's better.
  22. Media set rebuilds do not appear to restore the missing snapshots. I'm going to upgrade Retro to the latest, and see if this is fixed. I don't see anything in the release notes, but I can hope.
  23. I tried using "copy backups" and selected "all backups" to do the equivalent operation, and it results in the same thing, except that it *appears* that the output media set is smaller. The original media set copy op seems to have copied the files, but not the 'snapshots'. The "copy backups" appears to have only copied the files in the backups that got copied, and that is only the "latest", and 0 or 1 previous. Of the two media sets I tried, one resulted in zero backups to "retrieve". The other resulted in one. I'm going to try rebuilding one of these sets to see if the backups "reappear". I'll report back.
  24. What's this about? It looks like debug output that didn't get cleaned up before release. Log for Script: rotate_Users Date: 11/1/2014 + Executing rotate_Users at 11/1/2014 1:02 AM To Backup Set Users_last... - 11/1/2014 1:02:00 AM: Transferring from Users LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 LmGet: ndex = 0 < 1 11/1/2014 4:02:29 AM: Execution completed successfully Completed: 523912 files, 144.2 GB Performance: 837.3 MB/minute Duration: 03:00:28 (00:04:11 idle/loading/preparing) - 11/1/2014 4:02:29 AM: Verifying Users_last 11/1/2014 5:08:07 AM: Execution completed successfully Completed: 523912 files, 144.2 GB Performance: 2302.3 MB/minute Duration: 01:05:38 (00:01:30 idle/loading/preparing) 11/1/2014 5:08:18 AM: Script "rotate_Users" completed successfully
×