Jump to content

Search the Community

Showing results for tags 'logs'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • 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

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 8 results

  1. I have gotten several strange errors in my log even though most client backups seem to proceed normally. I did have one client come up as reserved (error -505) which is what started me looking for problems. I fixed that by forgetting the source, reinstalling the Client software, and re-adding the Client (First Use). Thereafter the backup scripts proceeded normally. However when I went into the log to see why the client hadn't been backing up for two days, I found this...See attached log snippet. Can someone explain these errors and if they have something to do with the above issue or another affecting operation of the backup. I have not seen the line before, IFaceIPUpdate: gethostbyname error 1, (Authoritative Answer Host not found), hostname = ML-server.private Note that the hostname does seem correct and Retro Server runs scripts using the hostname (possibly by address, since that also is correct). No names have been changed for any reason, ever. You will note that these errors seem to appear in clusters around the dates I started having trouble (6/23/2015) with a client and not before. So far I have reinstalled/restarted that one client. The Server side was restarted by automatic script last Sunday (6/21/2015) on it's normal schedule with no untoward events. My signature line below indicates the current software and configuration information on this system. I am reporting this as a bug, really it's a mystery. If you all have seen it before and have troubleshooting advice, please let me know. This is the issue I have experienced since upgrading to the latest release. Retro Log_150625.rtf
  2. I noted an anomaly in my log: + Normal backup using daily_user_portable at 3/27/14 (Activity Thread 1) To Backup Set v9_daily_user... - 3/27/14 11:31:59 AM: Copying Users on agility 3/27/14 11:37:27 AM: Snapshot stored, 7.4 MB 3/27/14 11:37:32 AM: Execution completed successfully Completed: 16104 files, 2.3 GB Performance: 460.4 MB/minute Duration: 00:05:32 (00:00:29 idle/loading/preparing) - 3/27/14 11:37:33 AM: Verifying v9_daily_user 3/27/14 11:38:04 AM: Execution completed successfully Completed: 16143 files, 2.3 GB Performance: 4,983.8 MB/minute Duration: 00:00:31 (00:00:02 idle/loading/preparing) The odd thing is the diference between the files backed up, and the files verified. Why are there 41 more files verified than were backed up? ???????????????????????????? (Retro 10.5 engine running on Mac OS X 10.8.5)
  3. I also have this log, which is one of many. I seldom see the "verified" count match the "copied" count. + Executing Weekly_VM3_rotate at 4/1/14 (Activity Thread 2) To Backup Set v9_vm3_last... 4/1/14 5:52:15 AM: Recycle backup: The Backup Set was reset - 4/1/14 5:52:15 AM: Transferring from v9_vm3 4/1/14 6:08:15 AM: Execution completed successfully Completed: 238126 files, 53.1 GB Performance: 3,491.3 MB/minute Duration: 00:15:59 (00:00:24 idle/loading/preparing) - 4/1/14 6:08:15 AM: Verifying v9_vm3_last 4/1/14 6:08:39 AM: Execution completed successfully Completed: 3181 files, 3.2 GB Performance: 8,139.7 MB/minute Duration: 00:00:24 This is a "Copy Media Set" script, and has "media verification" and "Data compression" set in the options. What's up with this? Why does it copy 53 GB and only verify what looks like a subset of the last snap? (Note that the file count on that snap is 4043 files. Where did the missing 862 files? (Retro 10.5, Mac OS X 10.8.5)
  4. Retro 10.2.0 (221) engine on Mac OS X 10.8.4 on a Mac Mini. I have been having trouble with media set copies, and so have been very watchful of the operations that I do to ensure that the output is sound. I had a small media set, about 7.8 GB, we'll call it orig. I copied it to arch, with compression enabled in the script. The resultant media set was 2.2 GB, but had the requisite 203 files. I wanted to verify that the 2.2 GB was "enough" by running a script *without* compression enabled to "re-inflate" the data. I copied the copy to "zjunk" without compression, and the result had 203 files, and 2.2 GB. I then tried resetting zjunk, and copying orig to zjunk, which resulted in 7.8 GB and 203 files. I then tried copying arch (compressed) on top of the files already in zjunk, with options un-checked so that no duplicate elimination was done. The resulting zjunk was 406 files and 9.9 GB. It appears that "compression" is a one-way operation on media sets. un-checking the "compress" option in the script will NOT un-compress the resultant copy. It also appears that compressed, and un-compressed data can be "mixed" in a given media set. The media sets, therefore, have no "compress attribute". Is this as it should be? It would be nice to get more information on the compression. There are a few places where "amount saved" is put in the logs, but when estimating the amount of space/tape that will be required, that compression performance data can be really useful.
  5. Where are the Retrospect 10 for Mac log files located? When a backup operation is completed or fails, which log files are updated? I want to write a shell script that will check the Retrospect log files on a specified bases, and send out an SMTP update on whether the log files have been modified or not. In theory, the shell script will check the files modification date/time. Based on the schedule of the backups, if the log files have not changed in the expected amount of time, the script will blast out an SMTP message to the admin to check the Retrospect backups. This shell script is a tool to try and figure out whether Retrospect is running normally or hung up. Thanks for your time, Mac Updated* The log file seems to be located at: /Library/Application Support/Retrospect/operations_log.utx
  6. retrospect engine process in a new V10 upgrade is generating multiple pairs of log lines per second of the form: TVol::GetInfo: UGetVolumeInformation failed, /private/var/folders/Sw/blahblahblah MapError: unknown Mac error 22. i reported this some time back (under either v8 or v9). iirc, i was told that these are not a sign of anything wrong and can be ignored. even so, i consider it a significant bug and i'm not happy that a previously reported problem survived into v10. i don't like my log files getting spammed like this - for several reasons.
  7. I am rebuilding the catalogs on some Retro 6.1 tapes to see if I can restore from them. When the first rebuild was done, I looked at the log: + Executing Rebuild at 4/22/12 (Activity Thread 1) To Backup Set MercyShare10 [001]... !Backup Set format inconsistency (4 at 317871024) !Backup Set format inconsistency (4 at 317768288) !Backup Set format inconsistency (4 at 317960128) !Backup Set format inconsistency (4 at 36464464) !Backup Set format inconsistency (4 at 317530656) !Backup Set format inconsistency (4 at 295383072) !Backup Set format inconsistency (4 at 296098384) !Backup Set format inconsistency (4 at 293092656) !Backup Set format inconsistency (4 at 295433920) ... ... a whole bunch of these..... ... !Backup Set format inconsistency (4 at 314986544) !Backup Set format inconsistency (4 at 315011504) !Backup Set format inconsistency (4 at 315020688) !Backup Set format inconsistency (4 at 315034864) !Backup Set format inconsistency (4 at 315057760) !Backup Set format inconsistency (4 at 315054256) !Backup Set format inconsistency (4 at 315097008) !Backup Set format inconsistency (4 at 315105376) 4/22/12 10:09:19 PM: Execution completed successfully Completed: 3173 files, 39.7 GB Performance: 150.3 MB/minute Duration: 07:16:45 (02:46:45 idle/loading/preparing) What is this "inconsistency" it is complaining about, and then deciding that the rebuild went just fine!?? There were three tapes in this set.
  8. This logfile from my copy operation (DDS tape rebuilt from Retro 6 -> Disk media set) with Retro 9.0.1.401 shows some questionable attributes. + Executing tape-to-disk at 4/24/12 (Activity Thread 1) To Backup Set + Executing tape-to-disk at 4/24/12 (Activity Thread 1) To Backup Set MercyShare10-v9d... - 4/24/12 10:39:29 AM: Transferring from MercyShare10 [007] !Can't load source session tree for 9/25/10 1:00:05 PM, error -2249 ( could not find session) 4/24/12 11:24:16 AM: 1 execution errors Completed: 65 files, 1.7 GB Performance: 93.9 MB/minute Duration: 00:44:47 (00:25:50 idle/loading/preparing) - 4/24/12 11:24:16 AM: Verifying MercyShare10-v9d 4/24/12 11:24:58 AM: Execution completed successfully Remaining: 1 files, 0 B Completed: 64 files, 70,657 TB Performance: 159,835,728 MB/minute Duration: 00:00:41 (00:00:02 idle/loading/preparing) The script has two sources, each a tape media set containing about 3100 files, and 36 GB of data. There is considerable duplication between the two sets, so the second set is not expected to copy over much data beyond the changed files in the later snaps. The main thing I notice is that the amount of data moved is clearly wrong, both in the number of files, and also the total data. The first rate (93 MB/min) is reasonable, but the other (159 TB/min) is a little off.
×