Search the Community
Showing results for tags 'slow'.
Found 3 results
I have Retrospect for Windows installed on an HP z800 workstation running windows 7 sp1 64bit. I have dual Xeon X5660 which has 6 cpus each with hyperthreading and 48GB of memory. I am copying from an 8TB raid array which has a speed of 635 GB/s reading 4k sequential according to crystalmark 5. I am backing up to an 8TB seagate usb 3 drive capable of writing 170 GB/s 4k sequential. I backed up 7098.3 GB at 2263 MB/min which took 2 days 6h and 33 mins.That is about 38 MB/sec which seems very slow. Is there any way of optimising Retrospect with respect of writing to drives. Regards Trevor
Hello, this note is a reminder to the community to use .metadata_never_index at the root of your backup drive to stop Spotlight from competing with Retrospect for access to the same drive. After searching the Knowledge base and the user forums, I didn't actually find this information - although the topic is so basic it is probably present and I missed it. In case it is useful to other searchers, I am providing this note because this morning I spent a fair amount of time trying to debug what appeared to be an 11.5.3 performance problem in Retrospect which turned out to be caused by the MacOS Spotlight feature. This is not a Retrospect problem, however it would be a useful Retrospect default option to automatically create a .metadata_never_index file in the directory containing the Media when you create disk Media in Retrospect. Symptom: Retrospect server reported performance drops to a surprisingly low <100MB/min in Details section of "Activity Pane" on a running script. Alternately, cumulative reported performance in the log file less than 500 MB/min. Environment: Retrospect Server and client running on the same MacBook Pro Retina 15. Yosemite 10.10.1. 16 GB RAM. Backup volume is a new volume (fresh erase), first Media write of Retrospect backup (new catalog). Catalog stored on backup volume. Source drive was an SSD. Backup drive was a WD 750 GB drive. Possible Cause: a new volume with significant MacOS Spotlight activity competing with Retrospect for access to the same drive. Solution: disable Spotlight indexing on the backup volume (this is the normal preference as such spotlight indexing provide no value to a backup volume) Methods to disable Spotlight on a backup volume -- System Preferences/Spotlight/Private is the most discussed approach, but I found it unreliable - perhaps because I was changing volumes. -- most reliable method: from a terminal window (Applications/Utilities/terminal) create any file (can be empty) named .metadata_never_index at the volume or drive root level. ----- the command I used was ---------- sudo cat /dev/null > /Volumes/<yourBackupDrive>/.metadata_never_index ---------------- if sudo has permission issues you can enable root access (dsenableroot & dsenableroot -d to disable) to briefly sidestep the permissions. ---------- although it is probably not necessary, after creating the file I rebooted to be sure that Spotlight noticed the .metadata_never_index file. In my particular case, I was using a WD7500AYYS 750GB drive over FW800 via the MacBookProRetina Thunderbolt adapter. Using Drive Genius 4 "Speed" testing, disk access dropped to a reported 10.25 MB/sec when Spotlight was indexing the new Retrospect data. After executing sudo cat /dev/null > /Volumes/<yourBackupDrive>/.metadata_never_index the reported speeds from Drive Genius went to 47 MB/sec. Log file reported that backup performance improved from 349.4 MB/min to 1,386 MB/minute. Verify operation 4,374 MB/minute (SSD source drive, WD 750 GB destination drive) If I see other performance problems which indicate some other cause, I'll update this post, however the problem is repeatable (erase backup volume) and the solution is repeatable, so I think this is the root cause. best regards, parker9635
Three times now, I have seen this with Retro 9.0.1 (401) on two different machines. This time I got some debug information. Retro 9.0.1 (401), OS is Mac OS X 10.5.8, Intel mini. (2006, dual core), 2 GB memory. All data on external FW disk. Operation: copy contents of media set from rebuilt 6.1 backup set to a new "disk" media set. No clients involved. Behavior: the operation was proceeding, but appeared to get slower and slower over time. We're talking SLOW (2.9 MB/min) I noticed that one of the CPUs was pegged, with 49% in RetroEngine, and 49% in notifyd. When I killed notifyd, the slowness stopped, and the operation finished. This time, I did a sample of notifyd and the Retro engine, in hopes of telling what it's doing in this tight little loop. (enclosed zip file contains 2 sample files, compressed) Embrace.zip