Jump to content

How to duplicate disk without copy everything again?


don69
 Share

Recommended Posts

I have a 3TB external backup disk that I have moved from Mac 1 to Mac 2. The content is almost identical on both Macs and the backup disk, but if I start a new duplicate from the 2nd Mac to the backup disk (the backup disk was previously duplicated from Mac 1), Retrospect will first delete all the files on the drive and then copy them over again. As this will take a couple of days, and about 95% of the files are already on the backup drive, how can I get Retrospect to see them and leave them, and just copy o er the new stuff?

 

Other backups software I have used in the past have been able to set different criteria such as file name only, name and date only etc. I can't find how to do that with Retrospect. Any ideas would be greatly appreciated.

 

I'm using Retrospect 6.1 on 10.6.4.

Link to comment
Share on other sites

Retrospect does not work like Carbon Copy Cloner/rsync when "duplicating" media. The behavior you see is "by design".

...

Well, my experience (details) is that the Retrospect "Copy/Overwrite entire volume" copies an amount mysteriously intermediate between everything and the actual updates made on the source volume with respect to the destination.

 

I never got any reply about why that might be so.

 

Anyway, by my reading of the manual (for 8.2, p147),

Overwrite entire volume

...

Retrospect saves time by not copying identical files, that is, files that share the same location, name, modification date and time, etc., that are already present on the destination.

...

Retrospect "Overwrite entire volume" is at least supposed to work just like CCC/rsync, and if it is, the name chosen is really a bit misleading.

Link to comment
Share on other sites

I guess I've never tried the "overwrite entire volume" option -- I should see what that does.

 

As far as 6.1 running on 10.6.4 -- the official company line is "it's not supported". It may *work* (I've done some test things with it and found some things worked fine and other things were buggy) -- but it's not supported by the company.

Link to comment
Share on other sites

Hello, I have just downloaded the 30 day demo and I came here to ask the same question don69 posted.

I think he - like me - is trying to reproduce the same behavior found in Retrospect 6.1 with the "Duplicate" option.

In 6.1 there was an option to "replace the entire disk" which used to delete all files and folders on the destination which do not match those marked for duplication, leaving files untouched if they are identical to files marked.

It then duplicates remaining files and folders from the source, preserving the folder hierarchy.

Despite its fearful name, this option used to create clones without the need of copying files already present on the destination and thus saving much time.

Files deleted from the source would be deleted from the destination as well.

Unfortunately it seems that none of the options in version 8.2 can provide the same result.

The "overwrite entire volume" in Retrospect 8.2 does indeed delete the destination before starting the copy.

Is there an option among those available which perform a duplicate like version 6.1 used to do?

I tried a few test and I could not find a way.

This would be a major issue to me, as I would just need that.

Many thanks for your attention,

Cheers!

Carlo

Link to comment
Share on other sites

...

The "overwrite entire volume" in Retrospect 8.2 does indeed delete the destination before starting the copy.

...

As I said in my post (and backed up with a link to an earlier post with actual data), but which seems to have been ignored so far in the discussion, "overwrite entire volume" in Retrospect 8.2 does not delete the whole volume and re-copy everything. Neither does it appear to really do what the manual says it does, and only copy modified files.

 

Here's the log of an copy of ~108 MB using "overwrite entire volume" to an empty destination volume:

+ Copy using Test Copy at 29/08/10

To volume NO NAME...

- 29/08/10 10:52:12: Copying Beyonwiz

29/08/10 10:54:10: Comparing NO NAME

 

*File "/Volumes/Cambyses User/Users/prl/Computer/src/Beyonwiz/.DS_Store": didn't compare

29/08/10 10:54:32: Execution completed successfully

Completed: [color:red]961 files, 107.9 MB[/color]

Performance: 93.1 MB/minute (55.3 copy, 308.3 compare)

Duration: 00:02:19

 

Both source and destination are formatted HFS+. Retrospect public release 8.2, OSX 10.6.4 MacBook Pro 2.26GHz/4GB.

 

Then I did a second copy to the backup, without changing any files:

+ Copy using Test Copy at 29/08/10

To volume NO NAME...

- 29/08/10 10:55:10: Copying Beyonwiz

29/08/10 10:56:09: Comparing NO NAME

29/08/10 10:56:22: Execution completed successfully

Completed: [color:red]47 files, 50.3 MB[/color]

Performance: 92.8 MB/minute (58 copy, 232 compare)

Duration: 00:01:12 (00:00:07 idle/loading/preparing)

 

And then again:

+ Copy using Test Copy at 29/08/10

To volume NO NAME...

- 29/08/10 10:56:47: Copying Beyonwiz

29/08/10 10:57:41: Comparing NO NAME

29/08/10 10:58:08: Execution completed successfully

Completed: [color:red]46 files, 50.3 MB[/color]

Performance: 75.4 MB/minute (56.9 copy, 111.7 compare)

Duration: 00:01:21

 

If its own reports are to believed, it is clearly not erasing and completely re-writing the destination volume. It is also clearly not doing a proper incremental copy, because it should have copied almost nothing, because I didn't modify any files on either drive (except for incidentals like .DS_Store, which it's hard to avoid modifying). I certainly didn't modify anything like enough for it to need to copy 50MB, nearly half the original copy.

 

There's definitely something not quite right about the descriptions of this operation (the manual flatly contradicts the GUI messages), and what it actually does (which corresponds to neither the description in the manual nor the "erase the entire source [sic] before copying" in the popup when you start the script).

 

The popup even manages to get the volume that it's supposed to be erasing wrong. A copy that in fact erased the source before it copied it would not be much use at all.

Link to comment
Share on other sites

As I said in my post (and backed up with a link to an earlier post with actual data), but which seems to have been ignored so far in the discussion, "overwrite entire volume" in Retrospect 8.2 does not delete the whole volume and re-copy everything. Neither does it appear to really do what the manual says it does, and only copy modified files.

 

Hello,

I came here since I have the same problem as the OP.

 

We have an external person that does DVD backups for us. With our old 6.x Retrospect I always copied the folder to backup to a mobile harddisk in the middle of the week. At the end of the week I did it once again, and just the changes were written. That saved a lot of time.

 

Today I did the same with our brandnew 8.2/Mac. The complete external drive got cleared and everything was copied from the beginning.

 

When I look at the script, the options overview says „Overwrite existing identical files“ (my translation from german version), however, I can not find a place where to change that - and the manual explains this option only for a restore, not for copying.

 

So, how can one make 8.2 to behave like 6.4?

 

Thanks,

Jörg

Link to comment
Share on other sites

  • 4 weeks later...
I have a 3TB external backup disk that I have moved from Mac 1 to Mac 2. The content is almost identical on both Macs and the backup disk, but if I start a new duplicate from the 2nd Mac to the backup disk (the backup disk was previously duplicated from Mac 1), Retrospect will first delete all the files on the drive and then copy them over again.

 

 

Mac 1 was used as the Source of a Copy operation, moving its contents to 3TB

 

Mac 2 has "almost identical" files, and when Retrospect was asked to Match the files it contains against what was previously copied from Mac 1 onto 3TB it saw the files as different.

 

I'm pretty sure "almost identical" was not considered to be close enough when the software was designed. It's likely the files on Mac 2 are "not identical," for whatever reasons (different modification dates, different block allocation size, etc), and as such Retrospect won't match them to the files on 3TB.

 

Having granular control over the matching criteria might allow you to get around this, but it's not a feature in Retrospect.

 

(note this does not address the observed oddities in Retrospect Copy matching, as noted above)

 

 

Dave

Link to comment
Share on other sites

I'll repost in the Bugs area' date=' then.[/quote']

 

Did you get a reply or even a result?

 

This problem forces me to run a separate machine for a retrospect 6.1 server that, funny enough, works in a unsupported environment…

 

Bye,

Jörg

I posted in the bugs section. No reply.

Link to comment
Share on other sites

Honestly, my first inclination (given the plethora of bugs) is to move easily duplicated (no pun intended) functionality to other applications. Carbon Copy Cloner and Synchronize Pro can both do the same thing (Synchronize Pro can even use fsevents to greatly reduce scan time), and both allow more control while working well. I used to do this even when using v6.1 in some cases, as the scanning was often faster.

 

Also, one other option to check is whether ACLs are being copied or not, and whether or not they would be the same on both volumes- that could easily cause otherwise identical copies to be listed as significantly different.

Link to comment
Share on other sites

Synchronize Pro

 

Unfortunately these guys dare to ask for $110 for a localized version and (here it goes even more crazy) $80 for an update. One more case of „Hey, it´s for Mac users, let´s put another 0 behind the price“.

 

I had very good results by compiling rsync 3 on a Mac with all features enabled (ACL, Extended Attributes,…), rsync has no additional dependency and is built in 5 minutes. It works like a charm, even with „difficult“ data like old PostScript fonts in Suitcases and RessourceForks.

 

There is scheduling builtin in every unix system (cron, launchd,…).

 

And last but not least we have network transparency with rsync, since from my point of view a backup attached to the backuped machine is useless. rm -rf / kills both.

 

Bye, Jörg

Link to comment
Share on other sites

I don't know about the localization issues, but it does do a nice job with network backups (and given the work that can go into localization, I'm not sure a one man shop should bear the brunt of that- after all it is still a fraction of the price of Retrospect). Plus it is good for two non-simultaneous uses.

 

As for the utility of local backups, they certainly have their place and can be extremely useful for certain kinds of recovery, but any disaster recovery plan needs offsite as well (after all, a lightening strike/power surge could take out every machine on site).

 

But if you have a situation where your main data is sitting on a machine where any user could walk up to it and delete everything, well- there are other issues there. If data security is important, minimizing the avenues for a user to wreak havoc is important. And if you are worried about the admin doing so...well, that's a whole 'nother user group.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...