Jump to content

Extremely poor (slow) performance while duplicating to external FW HD

Recommended Posts

My new copy of Dantz 6.0.178 took over 48 hours to duplicate 30 GB of data on a 80 GB harddrive to an attached external Firewire harddrive. The system slowed down incredibly while the duplication was running. Two days ago I redid the duplication, and although there was only 2 GB of data that had changed and needed to be duplicated, Retrospect still took 26 hours to accomplish this. Again, the system responded very slowly during this 26 hour time period. Interestingly, although I didn’t watch the Retrospect window the entire time, it seemed to spend hours and hours “closing” after the initial copy but before the verify. The final log said that data was transferred at a ~250MB/min rate, but obviously this doesn’t jive with the 26 hours it took to accomplish this 2GB duplication task. However, the duplication did seem to succeed after waiting the 26 hours with no error messages.


Is this slow rate of transfer inherent when duplicating to a Firewire drive in version 6? The task is much faster when backing up the old fashioned way to an AIT tape drive. Any suggestions would be greatly appreciated.


Thank you!


G4 867MHz, OS 10.3.3, 512MB RAM

Link to comment
Share on other sites

Here's the log for the second reduplicate effort:


+ Executing Immediate Duplicate at 3/27/2004 11:27 PM


- 3/27/2004 11:27:34 PM: Copying Achates HD…

3/29/2004 1:42:27 AM: Comparing Achates on BigDiskAES…

3/29/2004 1:53:34 AM: “aa” execution errors.

Completed: 10153 files, 2.6 GB

Performance: 3.3 MB/minute (1.6 copy, 234.9 compare)

Duration: 26:26:00 (00:03:15 idle/loading/preparing)


(there were ~90 errors that I abbreviated "aa" because I had to use my computer for regular activities during the 26+ hours it took to copy 2.6 GB, so I am assuming these were changes in used files inbetween the initial copy and the final verify).

Link to comment
Share on other sites

This seems way too slow ..


Have you tried doing a normal backup instead of duplication?


Here's a few other ideas to check out:


1. What speed is your computer and how much RAM do you have? Are you on a current system or way old? Have you got say a min of 256MB or more RAM? Have you got plenty of spare HD space on your main drive? Everything will suffer if your HD is nearly full, RAM is low, too many resources are being used or cpu speed is low (eg < 500 MHz is probably the lower useful limit).


What are these activiaties?"because I had to use my computer for regular activities during the 26+ hours it took to copy 2.6 GB" .. stop doing it and then try it..


2. What O/S are you using - check the system performance while it is running - how much RAM does RS use? How much is left for everything else? Is RS getting most of the CPU? Try making sure that nothing else is running at the same time .. ie use the scheduler to do this at night not while you use it.


3. Is it the Firewire that is the problem? Try doing the whole thing on a section on your existing HD.You should be looking for say 120+ MB/min .. not 3 MB/min. On some slower systems with low RAM or other poor performance reasons .. this could drop to 40-60 MB/min.


4. Try copying a 1-2 GB file to your Firewire HD .. how is transfer performance?


5. What else is on your system or network that could slow it down? I've seen performance improve just by improving seemingly unrelated issues such as the network, other computers connected to the network etc .. that weren't even running under RS.


6. Check RS settings very carefully .. uncheck the Workstation security settings one.

Link to comment
Share on other sites

Earlier today Dantz released Retrospect 6.0.193, an update to Retrospect 6.0 for Macintosh.


This update makes some very important fixes to Retrospect 6.0, including dramatic speed improvements when copying the file permissions during a duplicate or restore. Specifically this will speed up Retrospect while "closing" the execution.


This update is available at http://www.dantz.com/updates


Other changes include support for 10.3.3. For a complete list of changes see below:


Tape Autoloader and Fibre Channel Tape Libraries: This build includes an updated Device Access bundle (version 1.0.5) that provides a workaround to a Mac OS 10.3.3 bug that prevented tape autoloaders and fibre channel tape libraries from working.


Slow Duplicates and Restores: Retrospect has made changes to the “closing” phase of these operations to increase speed.


Media Capacity Display: The Media Capacity window for backup set members now correctly indicates that the displayed capacity is in GB, not MB.


Retrospect “Hangs” or Generates Error 108: Retrospect no longer hangs or generates an error when accessing older (pre-6.0) backup sets with many sessions.


New Media Backups to Older Backup Sets: Retrospect now allows "New Media" backups to older (pre-6.0) backup sets. As with all New Media backups, a new backup set is created (in this case a 6.0-compatible backed set) with a similar name to the old backup set.


Recreating Catalogs for Internet Backup Sets: Users should no longer see the error “assert at module.c-654” when recreating Retrospect 5.1 Internet backup set catalogs.


Restoring from Older Internet Backup Sets: Users can now restore data from older (pre-6.0) Internet backup sets.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...