Search the Community
Showing results for tags 'clone'.
Found 4 results
I am running Retrospect Desktop v18.104.22.168 on a Windows 7 Pro system. Earlier this year, I cloned a complete backup set from a 1TB external drive to a 3TB external drive using a partition manager called MiniTools. My Retrospect scripts continued working with the new cloned drive without a hiccup. Not only have the backups continued working, but I have done restores from the new drive, too. All was good! Last weekend, I cloned another complete - but different - backup set from a 2TB external drive to a 4TB external drive. I followed the exact same procedure I used earlier in the year (I took screenshots the first time). However, Retrospect is not finding the new backup set when I run my backup script, it appears: The volume label, file system type (NTFS), allocation unit size and the number of files and folders are all identical as one would expect after a disk clone. Of course, I extended the partition on the new drive during the clone to take advantage of the entire 4TB. The only odd thing is that, if you look at the member properties for the new 4TB drive, it says it’s 2TB in size. What am I missing? My research in this forum hasn’t turned up anything except that Retrospect uses UUID for identifying disks. I’m not sure if this a new feature in Retrospect v12. Besides, if it DOES use UUID then why did my earlier clone this year work? (I think I was on v12 of Retrospect when I did the earlier clone this year). Ideas anyone? bryan
Copying folders or disks with Retrospect 11.5 (Mac OS X 10.9.5) results in many cases in changed modification dates. With later copies these files are copied again and again whereas the originals were never changed. In addition I found that additional file info is not copied in at leas some cases. So the result is not a true clone. This is not a problem with access rights as they are identical. I enclose the information of an original file and the information of the file copied with Retrospect (different modification date, missing additional information). A similar problem existed with earlier versions of Retrospect and could be changed setting a parameter to restore modification dates in the hidden preferences (select preferences with option key). However, the relevant parameter is not there any more. Any idea how to produce a real clone with Retrospect 11?
roobieroo posted a topic in Retrospect 9 or higher for MacintoshFirst off, I haven't enabled the "use attribute modification date when matching" since that was totally busted if you used ACL's and I'm not sure if they bothered to fix it with the latest update. I noticed that my clone script is now taking much longer than it did under the previous version of Retrospect which I think was 10.2. Since moving to 10.5, I can run a clone script and then as soon as it finishes, run the script again and it will copy huge amounts of data that has absolutely not changed from the first time the clone ran. I don't know what's so special about the files that it recopies each time or if it's just a bug with 10.5. In addition to the clone script, I also run a backup script which is scheduled to run not too far after the time the clone usually finishes. Both scripts copy all data on the drive but the backup will backup say 4GB's of data while the clone will copy say 30GB's each time even if the clone just finished and I immediately hit run again. Why would Retrospect be cloning so much data right after a clone script has just completed? Again "use attribute modification date when matching" isn't even turned on so why would it think there is so much changed data that should be identical? Is anyone else using Retrospect to clone drives and if so are you seeing similar issues? Mac OS 10.8.4 Retrospect 10.5.0
roobieroo posted a topic in Retrospect 9 or higher for MacintoshI have set up a copy script and according to the manual, selecting "overwrite entire volume" for the destination should only remove files that are not the same as on the source drive. Running the copy script again even right after it has completed erases the entire destination drive and copied everything all over again. From the manual "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 thedestination." but that is clearly not what is happening. I do have use attribute modification date when matching enabled as well. What is the point of scanning the entire destination volume during the copy if it's just doing to delete the entire drive and start over from scratch? Is this a bug? How can I keep a clone without having to recopy identical files on the destination every time? Retrospect 10.1.0 (221) running on Mac OS 10.8.4