V7.6 Deletes Files Before Duplication

[sgs2009]

Hi All,

We have just purchase V7.6 Single Server Unlimited Client For Windows. We have set up scripts for duplicating our files to a 2TB Iomega StorCenter. When they run it scans the user's local hard drive, then the StorCenter files, next it prepares to execute and then deletes the files on the StorCenter. Finally it copies the data from the client to the StorCenter. All the documentation and the program itself say it performs intelligent backups of only new or changed files after the first run to speed up the backups but this is not happening. Can anyone shed any light on this issue or better still provide a solution!

Thanks

Gary

[Mayoff]

If the files appear to be different to Retrospect, then they will get deleted before the next copy. Do you get any errors during the verification pass of the duplicate?

Edited October 20, 2009 by Guest

[rhwalker]

If you have a way to view detailed metadata, see if the owner and creation/modify times are exactly the same (down to fraction of a second) on the source and destination. I.e., does the StorCenter's underlying filesystem support the same metadata model as the local drive?

[pmadland]

I have the same problem. the bundled software and hardware from EMC doesn't work together. Here are the specifics:

EMC iomega StorCenter ix2-200, NAS drive (2days old), with

EMC Retrospect Express v7.6 (most recent download), won't do "duplicate" backup as advertized: "only changes will be coppied". It deletes and recopies many files, even when there are no changes to the source files.

The problem appears to be the ix2 management of "Date created".

 

Here's a scenario that shows the problem with and IX2 NAS but not a problem with an XP file server.

1) Find/create a Windows Vista x64 file with "Date created" later than "Date modified"

2) Copy the file using windows explorer from Vista File system to the ix2 NAS file systems.

3) look at the dates. IX2 incorrectly sets+shows ix2 file's Date Modified = ix2 file's Date created = vista file's Date modified.

Other forums have reported this problem.

The incorrect handling of the date fools Retrospect to think there is a change that needs updating during a subsequent "duplicate" backup.

If I repeat the cut/paste test with a windows XP shared file system, then, correctly, the Date Created and Date modified for the XP file are the same as the original Vista file.

 

EMC should test their software a bit more with their recently purchased, iomega company.