Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ewilen

  • Rank
    Occasional Forum Poster
  1. I got the same error on first backup of a RHEL 5 client. However this backup reported 'execution incomplete'. The error was also reported in these threads: http://forums.dantz.com/showtopic.php?tid/14843/ http://forums.dantz.com/showtopic.php?tid/17840/ http://forums.dantz.com/showtopic.php?tid/14297/ ...and some others. While several of those threads discuss actual problems, it generally doesn't look like code 111 indicates a major issue, since several people report getting the code and still being backed up. Based on some more searches, I think that 111 is a tcp-level error meaning "connection refused".
  2. ewilen

    backing up hard links

    With the help of Dantz support, it looks like I've got an answer. The key is: under Options>Unix Client, turn OFF "Use status modification date when matching". When I did this, hard linked files (with identical filename) weren't copied again, but the link structure was restored on a restore. Many thanks to Dantz support.
  3. ewilen

    backing up hard links

    Thanks, I did check that and made sure that matching was turned on. In particular I have "Match source volumes to Catalog File" and "Don't add duplicates to Backup Set" turned ON, and "Match only files in same location" turned OFF. In the middle of the test I did a backup without doing any linking/unlinking, and nothing was backed up, as expected/desired. However I did err a bit in my description of the problem. When I created the link and backed up, Retrospect only copied 1 file, but it verified 2. Here are the log entries from my tests. First file created/backed up: Hard link created/backed up: Backup without doing anything: nothing copied:
  4. ewilen

    backing up hard links

    Hm, no answer. Well, I tried an experiment myself: Installed Linux_Client-7_6_100.rpm on RHEL running under VirtualBox. Backed up the desktop using Retrospect 7.6.123 (Windows) Created a hard link within a subdirectory on the desktop (linked to a file on the desktop). Backed up again. Result: both the "original" file and the new link got backed up. In fact it seems that when I delete the file in the subdirectory and do another backup, the original file gets backed up another time. I don't know if I'm doing something wrong or if I might be misinterpreting what I'm seeing in the Session Contents reports, but this is pretty sub-optimal behavior. If anyone else has any insights or suggestions, I'd be grateful. What I'd like to see, ideally, is that the contents of hard-linked files wouldn't be re-copied--Retrospect should just keep track of the linkage information.
  5. I am looking to back up a Linux server running Zimbra. Since Zimbra uses a lot of hard links, I was gratified to find that even my old copy of Retrospect Server for Mac OS Classic would backup and restore hard-linked files correctly from a Mac OS X machine. However it's not immediately clear how much space is actually used on tape. Now in this new situation, the Client is RedHat Enterprise Linux and the server is Retrospect (Windows) 7.6.123. What I'd like to know is... 1) Are hard links still backed up/restored correctly? 2) Suppose a file is backed up in one session, and then a hard link to the file is created. In the next session the hard link is backed up. Is the entire file copied again, or does Retrospect just record the existence of the link? 3) Suppose a file and a hard link to the file are both created between backups. Now a backup session occurs. Does Retrospect copy the file twice and note the existence of the link, or does it just copy the file once and note the link? Item (1) is most important to ensure data integrity. But (2) and (3) are also rather important since people who "naively" use other backup systems with Zimbra have reported that their backups ended up being several times the size of the data source.
  6. Let's see, the original problem surfaced using Office Depot 80 700 Mb CD-R's (nothing on the disks indicates the speed). Problems confirmed using Verbatim DataLifePlus 700 Mb rated at 48x. Also confirmed using TDK 700 Mb rated at 52x.
  7. I am having trouble using Retrospect 6.x with a Powerbook G4. Hardware: Powerbook G4 12" Drive: MATSHITA CD-RW CW-8122 version BA21 Driver: Panasonic CD-RW (5.10) (Note: this drive is supposed to be Qualified as noted at http://www.dantz.com/en/support/compatibility_list_detail.dtml?id=8931 ) OS: Mac OS X 10.2.8 I was able to create a backup set using this drive; all disks were written to and then verified successfully. The first disk initially showed up as "Incompatible" when re-inserted during the verify, but after being ejected and re-inserted, it was recognized. However, every time since then when I try to access the disks, they show up as "incompatible". (It doesn't matter if I am doing Tools:Verify, or a Restore, or simply looking at the Configure:Devices window.) Some things I tried: 1. Burning a CD using the Finder. Works fine; disk can be ejected and is recognized when reinserted. 2. Reading a CD backup set created on another Mac. Works fine. 3. Using the other Mac to read the CD backup set created on the Powerbook. Works fine. In other words, the CD drive appears to work for all purposes except that Retrospect cannot read discs which it burned on that drive. One thing I tried was creating a custom configuration for the drive. However, this produced similar results. I was able to create a backup set. This time, the third disk showed up as Incompatible on Verify, only to work when I ejected and reinserted it. After performing the backup, I attempted Tools:Verify, and once again the disks showed up as Incompatible. The only other clue I have about this is that when the disks are inserted in the Powerbook, the drive seems to be taking a long time to recognize them, and in the process it makes a lot of "clicking sounds" as if the drive head is seeking all over the place. This doesn't happen with disks that are burned in the Finder or which are burned using Retrospect on another Mac. This is a major problem since the Powerbook in question is normally used by a person in a remote office. While I was able to restore her data this time using a different Mac, that isn't an acceptable solution in general. Can anyone help? Thanks. --Elliot Wilen