jeg Posted April 17, 2003 Report Share Posted April 17, 2003 I have backed up about 20 GB from my internal disc to an external disc (as a complement to my backup sets on CD). When I add to the backup set ("Normal backup" doing an incremental backup) Retrospect Express reports that it will backup for instance 1 GB. In reality Retrospect Express seems to first write 20 GB to the external disc followed by the 1 GB. Then it verifies the 1 GB. My problem is that at the moment my external disc is connected through USB 1.1 and making this incremental backup therefore takes longer than a backup to a new backup set. Or in other words, an incremental backup of 1 GB takes 16 hours which is quite absurd. Have I misunderstood something? I have tried to find the answer in the documentation and in this forum (FAQ etc.) but have not yet found anything that explains this. I am also using a Veritas product but have to say that Retrospect looks like a good product and I am starting to appreciate it more and more. Link to comment Share on other sites More sharing options...
AmyJ Posted April 24, 2003 Report Share Posted April 24, 2003 Quote: In reality Retrospect Express seems to first write 20 GB to the external disc followed by the 1 GB. Then it verifies the 1 GB. I think what you may be seeing is the scanning / matching passes where Retrospect scans the entire drive to determine which files actually need to be copied. Look in your Operations Log for more details on the operations (Ctrl - L). If this doesn't help, please provide more details on your script set up (sources, destinations, number of scripts in use). Link to comment Share on other sites More sharing options...
jeg Posted April 28, 2003 Author Report Share Posted April 28, 2003 No script. Immediate backup. I guess it is the scanning / matching passes but I can see through Windows XP that Retrospect Express actually writes more than 20 GB before the 1 GB incremental backup starts. Is it not enough to read "modify date/time", check "modify date/time", decide which files need to be backup up (1 GB), backup these files and then verify them? What Retrospect seems to do is to read "modify date/time", copy all files (20 GB), check "modify date/time", decide which files need to be backup up (1 GB), backup these files and then verify them. As I said, I am doing an "Immediate backup" against an existing backup set (20 GB) and only 1 GB has changed. Since Retrospect insists of moving much more than 20 GB to do this, the net effect is that an incremental backup takes longer time than a new backup. I have used various backup software for many years (incl. Retrospect some years ago when I used a Macintosh) so I should know what I am doing but in this case I must have misunderstood something very obvious... Jan-Erik Link to comment Share on other sites More sharing options...
AmyJ Posted April 28, 2003 Report Share Posted April 28, 2003 Quote: I guess it is the scanning / matching passes but I can see through Windows XP that Retrospect Express actually writes more than 20 GB before the 1 GB incremental backup starts. You see this through Windows XP? How? What exactly are you looking at? Quote: Is it not enough to read "modify date/time", check "modify date/time", decide which files need to be backup up (1 GB), backup these files and then verify them? That is precisely what Retrospect does. However, all files must be scanned in order to determine whether the dates have changed. Retrospect does not copy them to the disk - it only scans the source and the destination and then matches files. The end result is that only unique files are copied to disk. If this does not answer your question, please outline _exactly_ the behavior you are seeing in reproducible steps. Link to comment Share on other sites More sharing options...
jeg Posted April 30, 2003 Author Report Share Posted April 30, 2003 Quote: You see this through Windows XP? How? What exactly are you looking at? Ctrl-Alt-Del : Processes : Configure the colums to show "I/O - Bytes read" and "I/O - Bytes written" : Look at the Retrospect process. If the value on the Retrospect process under the column "I/O - Bytes written" is much more than 20 GB I assumed that Retrospect actually transferred all data from the internal disc to the external disc before it compared the files. If not, what >20 GB is Retrospect writing and where? Other indications are the free space reported by Windows Explorer during the process (suddenly 20 GB "disappears" on the external hard disc) and the read/write light on the external hard disc that is constantly lit for 13-14 hours before Retrospect reports that the changed files are actually being backed up for another 2-3 hours (making the total time 16 hours). It seems unlikely to me that the comparision process should take 13-14 hours unless that much data was actually being transferred over a slow USB 1.1 link. Are "modify date/time" data not stored in a file somewhere? Jan-Erik Link to comment Share on other sites More sharing options...
AmyJ Posted May 1, 2003 Report Share Posted May 1, 2003 Retrospect must compare the files on the source to the files on the destination in order to match the files correctly. Matching is the scheme for comparing file attributes to determine whether files are identical, which then allows intelligent copying to avoid redundancy. Also see incremental backup. Retrospect uses several matching criteria to find new or changed files. If one of the criteria has been changed, Retrospect will back up the file again. On Windows, Retrospect looks at creation date and time, modified date and time, size and name. If match only in same location option is set, Retrospect matches on the path, volume name and drive letter also. Retrospect will report the current action in the GUI - Scanning, matching, copying, writing snapshot, comparing. You'll also find average performance data in the Operations Log (Window > Log). Take a look at how fast the data is being transported. This should give you some clues as to why the operation is taking so long. As a test, try backing up a gig of data to a file backup set on your local drive - rather then to your secondary backup drive. Do you see a dramatic performance increase? Link to comment Share on other sites More sharing options...
jeg Posted May 2, 2003 Author Report Share Posted May 2, 2003 I recently finished another backup. I started an "Immediate Backup" Wednesday 15.00. Windows Explorer reported that the only content on my external hard disc was "Backup Set A" that occupied some 21,5 GB and that I had 55 GB free space. Retrospect quickly scanned the about 20 GB on my internal hard disc. It decided that 1,7 GB needed to be updated/added in "Backup Set A" on my external hard disc. After that the Retrospect GUI did not show any life signs until Thursday morning. However, Windows XP reported that Retrospect was constantly writing so I did not give up. I wanted to see what would happen. Free space on the external hard disc was now 32 GB so apart from Backup Set A that occupied some 21,5 GB another 22-23 GB had become occupied. The Retrospect GUI woke to life Thusday morning as I said and reported that half of the 1,7 GB had been copied. For some reason the other half took another day. The backup finished successfully on Friday morning at 10. Windows XP reported that the Retrospect process had read 2 389 155 770 bytes and written 70 988 498 728 bytes. In other words, I was able to take an incremental backup from my internal hard disc to an external hard disc successfully. The only problem was that it took 43 hours to backup 1,7 GB!!! The last lines in the log follows: 2003-05-02 10:12:28: Snapshot stored, 75,8 MB 2003-05-02 10:14:33: 117 execution errors Remaining: 117 files, 1 825 KB Completed: 11309 files, 1,7 GB, with 15% compression Performance: 0,6 MB/minute Duration: 1 18:52:46 (00:01:49 idle/loading/preparing) instIniWriteItem: WritePrivateProfileString failed, error 5 instIniWriteItem: WritePrivateProfileString failed, error 5 Quit at 2003-05-02 10:23 instIniWriteItem: WritePrivateProfileString failed, error 5 The computer was not used by anyone while Retrospect was running. Execution errors reported are all normal changes done by Windows or busy files (error -1101 file not found or error -1020 sharing violation). The only thing that looks odd to me is that Retrospect reports "Duration 1 18:52:46" while my time was 43 hours. The other question is why it is writing 70 GB. Quote: Retrospect must compare the files on the source to the files on the destination in order to match the files correctly. Does it have to move the files in order to do that? Isn't it enough to compare file names, date/time and perhaps some kind of checksum? Quote: Retrospect will report the current action in the GUI - Scanning, matching, copying, writing snapshot, comparing. You'll also find average performance data in the Operations Log (Window > Log). Take a look at how fast the data is being transported. As you can see, Retrospect reports "Performance: 0,6 MB/minute". Even if USB 1.1 is slow it is not that slow. I would almost be faster with paper, pen and a floppy drive. When the Retrospect GUI is actually reporting something it says that the performance is at least > 10 MB/minute (my memory is not completely clear on this). Quote: As a test, try backing up a gig of data to a file backup set on your local drive - rather then to your secondary backup drive. Do you see a dramatic performance increase? I will do that and report the result. It has to be some kind of bug in action and it would be interesting to find it. Until then I will stick to my Veritas Backup Exec and treat Retrospect as a hobby project. Link to comment Share on other sites More sharing options...
AmyJ Posted May 2, 2003 Report Share Posted May 2, 2003 Quote: Does it have to move the files in order to do that? Isn't it enough to compare file names, date/time and perhaps some kind of checksum? No, files are not moved while matching. Quote: As you can see, Retrospect reports "Performance: 0,6 MB/minute". Even if USB 1.1 is slow it is not that slow. I would almost be faster with paper, pen and a floppy drive. When the Retrospect GUI is actually reporting something it says that the performance is at least > 10 MB/minute (my memory is not completely clear on this). The GUI will report dynamically report the speed during the backup - the speed will change based on the current action. The average speed of the entire operation is .6 - which, as you know, is extremely slow. Retrospect will write the data the same way to any local hard drive - so a backup to the internal drive vs. the external drive will be a good test. One other issue to consider is that Windows XP has a "System Restore" feature turned on by default. This option will attempt to cache large files created by Retrospect, which results in heavy disk activity and what appears like a freeze. Mutli-GB file backup sets are likely to trigger this behavior. The I/O activity you are seeing may be a direct result of the disk caching by WinXP's System Restore. If you wait an extended period of time, the disk activity will stop and the computer will once again be usable. To increase backup stability try turn off "System Restore" in the System Properties for "all drives" by going to: Control Panels > System > System Restore. If the file backup set is on a USB or Firewire disk, try the following: 1. Power down your machine 2. Disconnect the FireWire or USB hard drive 3. Re-boot 4. When the machine is back up, turn of the System Restore Start> Settings> Control Panel> System> System Restore Tab 5. Put a check in the Turn off System Restore box. Click Apply, then click OK 6. Power the system down and reconnect the external drive. 7. Reboot and try the backup again. Link to comment Share on other sites More sharing options...
jeg Posted May 18, 2003 Author Report Share Posted May 18, 2003 Quote: One other issue to consider is that Windows XP has a "System Restore" feature turned on by default. This option will attempt to cache large files created by Retrospect, which results in heavy disk activity and what appears like a freeze. Mutli-GB file backup sets are likely to trigger this behavior. That was the problem. The time for an incremental backup is now down from 43 hours to 1 hour. I have tried both making a new backup set and taking backup aginst existing backup sets and the problem is gone when the system restore functionality is turned off. Thank you very much for your help. I can now start using Retrospect for real work. Am I the only one who have encountered this problem? Dantz should write about this in their Help files. Link to comment Share on other sites More sharing options...
Mayoff Posted May 18, 2003 Report Share Posted May 18, 2003 The issue is outlined in our knowledgebase: http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27294 Link to comment Share on other sites More sharing options...
mrodby Posted May 20, 2003 Report Share Posted May 20, 2003 Thank you, Jan-Erik, for being so diligent in pursuing the answer to this question. I too have had this problem for several months, and wondered why. I even searched the KnowledgeBase for answers, using the words "slow", "long" and others, but did not see the article mentioned above, because it did not include any of those words. I was not looking for the word "hang" -- after all, the backup completed, it just completed very slowly. I have an external FireWire drive, and am backing up 18 GB of data. An incremental backup would spend between 45 and 90 minutes with the message "Preparing to back up" (or something like that) in the Retrospect status message box, and with the light on the external drive indicating constant activity. Dantz Support, please consider changing the title of the article from "My computer hangs when I write to a file backup set under Windows XP. Why?" to "When I write to a file backup set under Windows XP, the backup is very slow or hangs. Why?" or some such wording. That would have gotten my attention. Link to comment Share on other sites More sharing options...
jeg Posted May 28, 2003 Author Report Share Posted May 28, 2003 Just like you, I searched the documentation and the knowledge base but I never thought of the word "hang" because Retrospect didn't "hang", it completed its task although it took a very long time. I am a bit surprised that this kind of information should be buried deep down in a knowledge base and that it should take someone from Dantz more than two weeks to figure out what the problem was. Doesn't this problem affect everyone with the combination of Retrospect and Windows XP? Are all others using so fast systems so they don't notice the problem? The reason I observed this problem was the fact that I at the time only had access to USB 1 on my computer. I have since ordered (but not yet received) a very generously configured Dell 8300 with both USB 2 and Firewire so with "system restore" turned off the time it takes to backup my computer should decrease significantly. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.