Jump to content

fjk

Members
  • Content count

    25
  • Joined

  • Last visited

Community Reputation

0 Neutral

About fjk

  • Rank
    Occasional Forum Poster
  1. fjk

    Multi Server 7.7.341 (64-bit)

    I have similar issues with Windows Multiserver 7.7.341 64-bit. Some scripts run OK, others run but don't leave logs, and the program invariably disappears and only leaves behind a useless Monitor window, which does not let you do anything.
  2. I am running Multiserver 7.6.123 to back up a few dozen clients each night. The performance statistics I get seem to be meaningless. E.g. Completed: 108 files, 919.5 MB, with 19% compression Performance: 268.4 MB/minute (213.8 copy, 362.9 compare) Duration: 00:21:48 (00:14:57 idle/loading/preparing) Or for another system: Completed: 22 files, 4,741 KB, with 77% compression Performance: 2.5 MB/minute (34.7 copy, 1.3 compare) Duration: 01:33:27 (01:29:47 idle/loading/preparing) Or for a third system: Completed: 133 files, 914.6 MB, with 14% compression Performance: 128.3 MB/minute (123.8 copy, 133.1 compare) Duration: 05:22:57 (05:08:42 idle/loading/preparing) In this last case: over five hours to back up 914.6 MB ??
  3. I am running Multiserver 7.6 and am experiencing periodic freezes of nightly backups due to one or another client getting stuck at "open file backup". Why can't the Retrospect server go on to the next client? I have 80 Windows clients on one scripted backup run, and one client ends up holding the whole line. What gives?
  4. Answer found: one of my tape drives was causing this problem. When I disconnected my very old SCSI autoloader the multiple tape drive configuration behaved as expected.
  5. Yes. I have tried two different Adaptec cards: 29160 and 39160, both with current drivers.
  6. No errors in the operations log, including the detailed version, which Andrew Anderson of Retrospect had me compile. The tape drive just becomes inaccessible, all the action buttons are greyed out, but other Retrospect scripts proceed normally. Felix
  7. Here is my configuration: Retrospect 7.5 Multi Server running on a Windows XP machine including all the Add-Ons (Advanced Tape Support, SQL, Disaster Recovery, Proactive, etc.); About 90 Windows XP and Windows 2000 clients; About 20 Mac clients; RAID disk farm for primary storage for a total of 5TB; For secondary storage (archives) I use tape: Adaptec 39160 SCSI controller; HP Ultrium 460 external LTO-2 tape drive; Seagate Ultrium LTO-1 autoloader with 10 data and one cleaning tape. I allocated the Seagate autoloader to a continuing archive job, and it works OK. I use the HP single tape drive for periodic archives. The problem: I load the HP Ultrium with tape 1 and start a scripted archive job; Retrospect writes to the tape filling it with data, but after the tape fills up the drive becomes inaccessible, all the device control buttons (erase, eject, etc.) are greyed out and the script hangs. The other Retrospect scripts to disks and the other tape device continue to run normally. The only way to recover control to the HP Ultrium is to crash/restart Retrospect. At EMC engineer's suggestion, I disabled the Windows/HP driver and let the Retrospect driver control the HP tape drive. The problem persisted. Why does the Ultrium tape hang? Felix
  8. I am running Multiserver version 7, backing up about one hundred WinXP, WinXP Server and Mac OSX machines. Recently, I moved the application to a faster WinXP machine and experienced a few problems. The one that is puzzling me still is two WinXP clients, which both report: Error -557 Cannot back up registry (transaction already complete). Ordinary files on these clients seem to get backed up. What is this error and which transaction does it refer to?
  9. I moved my Retrospect 7 Multiserver to a new XP machine and on my next set of scripted night time backups a large number of clients, both PC and Mac, reported error -556. By trial and error I discovered that to fix these clients I need to "Add" them to my client database. I do not need to "forget" them out of the database, just adding them seems to do the trick.
  10. fjk

    Passwords and Clients

    In my experience, the only way to get out of this predicament (lost or corrupt client password) is to uninstall Retrospect client, reboot it, make sure the program is gone, then reinstall the client with a fresh password. Only then can you access it from the server. I found this to be true for both Mac and PC clients, unfortunately. The advice you get from Dantz seems bogus.
  11. I backup to sets of Firewire disks. I have four scripts, one for each of my four groups of clients. Each script writes to two different disks. One month, to one disk, the next month to another disk. So, this seems to be very similar to your idea. Retrospect knows to write to a particular disk because of its volume label, same as if it were tape media. As to your question 3, about the speed of moving contents of your Firewire drives to tape, I am running into severe speed problems transferring Snapshots. I already posted a plea for help, but I am not sure that Dantz Retrospect people have really worked this out.
  12. I am running Retro 7 for dozens of Windows and a dozen of Mac clients and using a set of 500GB Firewire-800 disks for nightly storage and a pair of SCSI tape drives for monthly archives. This is a perfect scenario for D-D-T solution, especially since I have different scripts with different selection filters for various groups of clients. I have read the White paper and tried to follow its suggestions. I elected to transfer all the Snapshots from each disk, but to select only the most current versions. I have run into two unrelated problems: 1) The speed of storing local disk Snapshots to tape is incredibly slow, about 80.8 to 100 MB/minute instead of the rated 900MB/min (this is HP Ultrium 215 drive). This is twice slower than my previous archives from clients directly to tape via the network. 2) The disk with the snapshots gets locked up, and my nightly incremental backup from clients to the disk is stuck in the "wait" state. Is this because I told Retrospect to copy all the Snapshots on the disk? The White Paper discussion of what a Snapshot is confused me. What is going on?
  13. A script locks up all the clients and does not release them until it finishes running. Is it possible that some failure during the script run would prevent all or some of the clients from being "unlocked"?
  14. All the disks are formatted with NTFS. I am up to Retrospect 7.0.249 on the backup engine. Nate, you misunderstood my complaint: Can two different scripts simultaneously use the same logical drive as the storage media? Disk drives generally allow simultaneous access by many processes. However, Retrospect treats all media as if it were sequential access media. More to the point: What causes the "Media unavailable" errors? Must I define multiple saveset members, even on the same disk, to ensure that my backup script runs to the end? If your answer is Yes, then why? Retrospect already complicates the disk storage structure by creating folders like: D:\Retrospect\M-1\1-M-1 Now, to solve the "Media unavailable" error I needed to create a saveset on the same disk: D:\Retrospect\Retrospect\M-1\3-M-1 What is the point of all these subfolders? I still have the same point of failure, my D: drive. I am not spreading the risk of failure, just complicating the placement of backed up disk images.
  15. I am using Multiserver 7 and hard drives as my primary storage media, with tapes as secondary archive media. The basic Retrospect approach is to forbid simultaneous use of same media by different scripts-savesets. This is probably a legacy of the days when tape was the only media. It is annoying, but I can get around this by having lots of external disks (or disk partitions). What bothers me more is the frequent inexplicable "Media unavailable" errors. The media disks are fine, have plenty of free space, but the script hangs with this error. I can fool Retrospect by adding another Saveset member to the set, even on the same disk, but it is still very annoying and dangerous. Why is Retrospect so obtuse about the use of disks as the storage media?
×