Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About nicelyc

  • Rank
    Occasional Forum Poster
  1. Due to a string of assertion failures and other unsavory errors, I recently rebuilt my backup server from the ground up (scripts, configurations, clients ... everything). But afraid that I would invest my efforts elsewhere if I had a reliable backup server, Retrospect has produced a fresh set of errors - never seen before - for my continued enjoyment ... Here's one of my personal favorites that I would like to share with you. I have about 80 laptops being backed up by a proactive script. When Retrospect starts backing up a client, it's status changes to "Execute" on the Proactive tab of the Activity Monitor. This is good. But all of the other clients' status change to "Media". I understand that the media is unavailable due to execution of another client, but I did not notice this behavior before. No big deal, but this is leading up to a more annoying problem ... For a brief moment, immediately after the backup begins execution, the media dialog is displayed. The target backup set member is indicated in the appropriate drive, but Retrospect is asking me where it is! Within three seconds, the dialog disappears, and the execution continues. In the mean time, Retrospect sends an email notification with the message "Script Laptop (Daily): waiting for media". Maybe Retrospect feels that I'm just not getting enough spam, and would like to dispel my lonliness with a few personal emails. Perhaps you could help me find a way to break the news gracefully that I would prefer a nice discussion over dinner, perhaps with some cocktails. Better yet, how about a long walk in the woods ... we could talk about the virtues of an early retirement (it's, not mine). Yes, Windows drivers have been disabled, and I am using the newest Retrospect build (6.5.343) and driver update (4.9).
  2. Thank you for your reply. As I stated (albeit vaguely), a restart (reboot) of the server (computer) was not effective. Sorry if I wasn't clear. To answer a few of your questions: - I am using three Quantum SDLT drives on an Adaptec SCSI card. - There does not appear to be any consistency with regard to the operation in progress when the assertion failures occur. But the operations log is lacking in detail, so it is difficult to reconstruct. - There are typically one or two operations running. But, again, there is no consistency. I went ahead and reinstalled Retrospect, and it has been running for about 20 hours with no assertion failures.
  3. Retrospect: Multi-Server v6.5.343 OS: Windows Server 2003 HW: P4/1.7GHz/384MB I have been receiving the following error, at least once a day for the past week: "Retrospect has encountered a serious error: Assertion failure at elem.cpp-861 ..." The assertion failure occurs at unpredictable times. It is not limited to any particular script or client. It has occurred during proactive backups, scheduled backups, and manual script executions. No antecedent events are apparent in the operations log. I have sent a copy of the assertion log entry to Dantz after some (but not all) of the failures. Restarting Retrospect does not solve the problem, and the assertion failure recurs. Restarting the server does not resolve the issue. After receiving the second such message in two days, I ran the Retrospect 6.5.343 update. No change. Of course, this is an untenable position, as the majority of our backups are not occurring. I am thinking of reinstalling Retrospect. But this is not a desirable solution, as it reveals nothing about the etiology of the assertion failure.