Jump to content

aandi

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

0 Neutral

About aandi

  • Rank
    Occasional Forum Poster
  1. Retrospect 7.6.123 on XP backing up an XP client to FILE. One backup task runs nightly to backup about 4 GB of PST files (from Outlook: no Exchange Server anywhere). Sometimes this runs at around 200+ MB/minute. This is consistent with the other clients around the place. But more often it runs closer to 10-20 MB/min. Stopping the backup and retrying sometimes gets the backup at the faster speed. Sometimes rebooting server or client seems to help, sometimes not. There is not a variation of speeds between these two extremes: it is either very fast or very slow. Outlook is NOT running. I speculate that something can cause the backup client to switch into a slower mode (locking?). I believe I have seen the backup start fast and switch to slow, but never go back to fast from slow. The client is not cluttered with extra software. It has XPSP3 and Office 2007 out of the box, and Retrospect Client is the only add on. This effect was seen on the PC which preceded this one, but is not seen on other similar PCs with large PST file sets. This has been going on for years, but the size of the PST files now means that it is typically overrunning into the working day. Thanks in advance.
  2. aandi

    Bad backup set header errors

    That's good to hear. (I have good reasons for using file backups, but I don't want to confuse the discussion with that at the moment: it wasn't a random selection, but the reason for choosing Retrospect). Given that the backups shouldn't be unreliable, can you suggest any way forward from the "bad backup set headers" message when doing a verification as part of the backup? I should say that there may be nothing wrong with the backups, since a later Verify Media does not give any suggestions of problems. Should tech support be able to help, or will they just tell me to use Disk backups?
  3. aandi

    Bad backup set header errors

    These may be good reasons, but the key thing is: are these backups now unreliable?
  4. aandi

    Bad backup set header errors

    One thing worth checking. I am getting this for DES encrypted backups (I also regularly get an assertion failure in des-cpp). I also speculate that the problem is actually in the verification, though I have still to do an exhaustive check of a backup that failed verification. Has anyone seen this on backups that are unencrypted or not using DES?
  5. aandi

    Bad backup set header errors

    This is shocking. Our entire backup strategy is based on file backup sets, and has been for years, without any problems until 7.5. We have been seeing this error, and trying to decide what to do.
  6. aandi

    Hardware for Multi-Server

    I can't watch it at the moment, but I'm pretty sure I've seen Retrospect spread itself out nicely on multiple cores. Of course, it can only use one core while one backup is running, but I have had up to 8 backups running very smoothly in parallel on a 4-core server.
  7. Setting everything up again runs the possibility of introducing errors, as well as being time consuming. Is there no possibility of a more systematic approach? An assertion failure, after all, is not a random crash. It's a decision made by a programmer to say "this situation is impossible, so it is better to crash the application than continue", and which can be taken direct to the source code. (As a programmer myself, I would really want the situation not to change in the hope of understanding the problem better).
  8. Since upgrading to Retrospect 7.5, there have been several assertion failures (followed by Retrospect shutting down until manually restarted). Here is the start of one: OS: Windows XP version 5.1 (build 2600), Service Pack 2, (32 bit) Application: D:\Program Files\Retrospect\Retrospect 7.5\Retrospect.exe, version 7.5.387 Driver Update and Hot Fix version 7.5.13.100 Exception occurred on 13/10/2007 at 22:29:17 Error info: Assertion failure at "des.cpp-270" Exception code: e0000000 ASSERTION Fault address: 7c812a5b 0001:00011a5b (null) The backups are to file backup sets on an external FW800 disk; DES encryption is indeed used. I have not been able to isolate this to a particular backup or backup set; all backup scripts and backup sets have been used multiple times without the assertion being raised either. This may or may not be related to an issue where verifies are frequently (and apparently spuriously) failing; I intend to post a separate message about that. What do I do next?
  9. Hi, Server: Windows XP, Retrospect MultiServer 7.5.387 Hotfix 7.5.13.100. Client: Windows 2000, 7.5.111 A particular backup is run each night (all *.PST files) and backs up 3-7 GB. Typically the backup rate is 150-190 MB/min. But perhaps once a week it slows down terribly, managing 10-15 MB/min. The backup is still running and the some PST files (mailboxes) are locked when the working day begins. I am looking for the cause/solution of this slow down, or tools to get closer to what is happening. I believe it also affects other clients, but I have yet to do a detailed analysis. I have checked CPU on the client: when doing the slow backup, the CPU use is negligible. The server has ample capacity and has completed its other backups, some overlapping, in the normal time. Does anyone know what sort of things could cause this - perhaps something switches the client into a different mode?
  10. There is a discussion about "closing" taking a long time, but that seems to be a regular problem where it does come to an end eventually. So I think the following is completely different. We are running Retrospect 6.5 Multi-Server, on a Windows 2000 Workstation, backing up a variety of clients to external firewire drives. At least once a month, sometimes more often, we see a particular problem when backing up a Windows client. The backup never completes. The log shows that the files to be backed up are all backed up (it says "Execution completed successfully"). The activity monitor however shows "Closing". The Client control panel shows this as "In use". This is of course a serious problem, requiring checking and potentially manual intervention each morning, typically rebooting both client and server, though restarting the service on the client also clears it. Even more seriously, other backups are queued up behind this, and so never get done, or get done during live time. If it isn't checked, the situation just continues - it has been almost a week in the worst case. This has affected several clients. The common thread seems to be that it has been backing up very large files (over a gigabyte). My questions about this are (a) is this a known problem with the client or backup software? I think even if there is a bug in the clients or a network problem, this must be a problem with Retrospect itself, since surely it should time-out when there is no response for hours. ( is this fixed in 7.0? It would be worth the upgrade if so.
×