backing up hard links

[ewilen]

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.

[ewilen]

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.

[rhwalker]

Check your matching options so that duplicate files don't get backed up.

[ewilen]

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:

- 9/8/2009 1:29:36 PM: Copying Desktop on zimbra-vm test

9/8/2009 1:30:11 PM: Snapshot stored, 70 KB

9/8/2009 1:30:13 PM: Execution completed successfully

Completed: 1 files, 377 KB

Performance: 0.6 MB/minute

Duration: 00:00:36 (00:00:04 idle/loading/preparing)

 

- 9/8/2009 1:30:13 PM: Verifying gbl_usrsvr_9-09_#1

9/8/2009 1:30:19 PM: Execution completed successfully

Completed: 1 files, 377 KB

Performance: 22.0 MB/minute

Duration: 00:00:05 (00:00:05 idle/loading/preparing)

 

Hard link created/backed up:

+ Executing Immediate Backup at 9/8/2009 1:33 PM (Execution unit 1)

To Backup Set gbl_usrsvr_9-09_#1...

 

- 9/8/2009 1:33:24 PM: Copying Desktop on zimbra-vm test

9/8/2009 1:33:34 PM: Snapshot stored, 70 KB

9/8/2009 1:33:35 PM: Execution completed successfully

Completed: 1 files, 377 KB

Performance: 3.1 MB/minute

Duration: 00:00:10 (00:00:03 idle/loading/preparing)

 

- 9/8/2009 1:33:36 PM: Verifying gbl_usrsvr_9-09_#1

9/8/2009 1:33:42 PM: Execution completed successfully

Completed: 2 files, 754 KB

Performance: 44.1 MB/minute

Duration: 00:00:06 (00:00:06 idle/loading/preparing)

 

 

Backup without doing anything: nothing copied:

+ Executing Immediate Backup at 9/8/2009 1:35 PM (Execution unit 1)

To Backup Set gbl_usrsvr_9-09_#1...

 

- 9/8/2009 1:35:10 PM: Copying Desktop on zimbra-vm test

9/8/2009 1:35:10 PM: No files need to be copied

9/8/2009 1:35:20 PM: Snapshot stored, 70 KB

9/8/2009 1:35:22 PM: Execution completed successfully

Duration: 00:00:12 (00:00:03 idle/loading/preparing)

 

- 9/8/2009 1:35:22 PM: Verifying gbl_usrsvr_9-09_#1

9/8/2009 1:35:22 PM: Execution completed successfully

[ewilen]

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.