Jump to content

ctwist

Members
  • Content count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ctwist

  • Rank
    Occasional Forum Poster
  1. This is an old thread, but it is still relevant. I had the same problem with Retrospect Professional 7.6; the size of my disaster recovery ISO file for Windows XP SP3 was 843MB. My solution was to burn a DVD instead of a CD. This is what I did: - In Retrospect, I used "Disaster Recovery" to create an ISO file, but I did not attempt to burn it. - I then used ImgBurn to burn the ISO file to a DVD. I did not need to change any settings; if any conversion of the ISO file was needed, it handled it automatically. - I was able to boot from the DVD. I haven't attempted a restore, but the DVD seems to be in the correct format.
  2. ctwist

    Normal backups, backing up too many files.

    I too have experienced this problem. Its description and a workaround follow. I sent this note to tech support on 16th June, but have not received a reply. ------------- When doing a full backup to multiple DVDs, if one of the volumes is defective, the entire volume is marked as defective, along with all prior volumes. This causes a lot of data to be backed up unnecessarily during the next incremental backup. Details follow: - I ran a full backup for a new backup set. The preview reported that the total file size was 17.9GB. Verification was turned on. - While the 3rd volume was being verified, I noticed that 1.5GB remained to be backed up. - When the backup was complete, the log reported error -206 on the 3rd volume (i.e. a damaged disk). - I started an incremental backup, which should have backed up the files that were not readable. However, the preview reported that it was going to back up 16.4GB. Since 17.9 - 16.4 = 1.5, this suggested that all the files on the first 3 volumes were going to be backed up again, even thought the first 2 volumes had no errors. I did not run this backup. - I then repaired the catalog, rebuilding it from the 4 backup volumes. - I started the incremental backup again, and this time it only needed to back up 41MB. I allowed the backup to run, and it completed normally. My conclusion is that when the verification process finds errors, far too many backed up files are marked as unusable in the catalog. This problem has happened to me twice. I suggest that you need to improve your error recovery process.
  3. I am using version 7.5.251. I ran a full backup; this backed up about 14Gb. I then changed the selector, so that it excluded temp folders and temporary internet files, instead of specifically identifying the explicit paths. To verify that I had done this correctly, I started an incremental backup, about 2 hours after the full backup had finished. This identified over 10Gb of "changed" files that needed to be backed up. Most of these files are identical to files that were backed up previously. This is a home computer, with very little activity going on. Is there any reason why a large group of unchanged files could be incorrectly tagged for backup?
  4. I have upgraded from 6.0 to 7.5. As stated in the documentation, the 7.5 installer cannot upgrade the 6.0 configuration; it uninstalls 6.0 before installing 7.5. This note describes how to upgrade your 6.0 configuration. This technique is completely unofficial, but it worked for me. The 7.5 installer retains the configuration from 6.5 onwards, so I first upgraded to 6.5 and then to 7.5. I downloaded 6.5 from ftp.dantz.com/pub/en/ud/retrospect65.exe. After installing 6.5, I was prompted for the licence code. Since I didn't have one, it immediately exited. However, it had already migrated my 6.0 configuration file. I then installed 7.5, and it converted the 6.5 configuration file to 7.5. I had some complex selectors, and these have survived the upgrade process intact. I suggest you try this. Since the 7.5 installer discards a 6.0 configuration, you have nothing to lose.
×