Note that rsync always verifies that each transferred file wasĬorrectly reconstructed on the receiving side by checking its Since this whole-file checksumming of all files onīoth sides of the connection occurs in addition to the automaticĬhecksum verifications that occur during a file's transfer, this Order to decide which files need to be updated: files withĮither a changed size or a changed checksum are selected for Receiver then checksums its version of each file (if it existsĪnd it has the same size as its sender-side counterpart) in ![]() Tem scan as it builds the list of all available files. It does this during the initial file-sys. This forces the sender to checksum every regular file using aġ28-bit MD4 checksum. here is the relevant portion on the manpage. No, you dont understand how rsync actually does it's thing. I think I need to read up on rynsc because on an ongoing basis, I'd prefer not to have to increase my backup time requirement by 50%. I'm comfortable that the new drive kept all the data intact because after 15 hours CCC said that 0 kb were copied (meaning that everything was a match) and I got no errors reported in the log. I think it took 10-ish hours to clone that much data on Thursday and probably took an additional five hours with checksum enabled. I ran CCC again on the same 900GB of data I cloned to the new drive on Thursday but this time enabled the checksum functionality. The alternative is a NAS that runs ZFS internally but that naturally is communicating with a Mac via SMB which doesn't support a number of properties of the Mac file system HFS+. There used to be a commercial version but the stopped development and have been taken over by Oracle (the actual developer of ZFS) last month which probably canned that project completely. The open-source implementation is stuck at a very old ZFS version as the stable branch and how stable the development branch is (which itself is a branch of the Linux version of ZFS), is something I don't know. ![]() Using ZFS drives directly with OS X however is not without problems. The two other solutions I'm aware of are the Integrity Checker from and running the backup drives using ZFS as the file system. And as suggested here, you can run the copy with one application and then use a second application to verify things. The very first thing, however, is to do what you are already planing to do: Use a (good) backup/sync application and not the Finder to the copy. The checksum feature in CCC is probably the best solution (for a one-time transfer it shouldn't matter too much if it takes a long time). There used to be a commercial version but the stopped development and have been taken over by Oracle (the actual developer of ZFS) last month which probably canned that project completely. The open-source implementation is stuck at a very old ZFS version as the stable branch and how stable the development branch is (which itself is a branch of the Linux version of ZFS), is something I don't know. The two other solutions I'm aware of are the Integrity Checker from and running the backup drives using ZFS as the file system. ![]() The checksum feature in CCC is probably the best solution (for a one-time transfer it shouldn't matter too much if it takes a long time). Seriously though, rysnc is an underused tool. Much faster.īTW, /backup in the earlier answers will be something like /Volumes/Backup1-Drive (whatever the name of the drive is on your desktop - and for sake of ease, have no spaces in the drive name). I'll check it out later when I'm home, as well as your suggestions in this thread.Ĭhecksum will take an age to run, but you could simply run rsync with "-size-only". They have checksum task functionality in CCC. Also, note that most of the cloner tools do NOT copy everything (some things like some caches or other not-needed stuff is often left out since it would be recreated automatically) Given that command line, you'll most likely see a short list of what is 'different' between the two directory structures. All that will happen is 'this is what would have transferred w/o the -n option' which is of course, OK in this case since it's merely for verification. Keep in mind that the use of the -n option means 'dry run' and that NOTHING WILL ACTUALLY BE TRANSFERRED.
0 Comments
Leave a Reply. |