How does 'mirror' decide that a file has changed? If it cuts down backup times so dramatically, presumably not by checksumming. I set rsync to go by filesize only, but there's obviously some risk still of undetected degradation. I just calculate that any such cancer is less likely to spread if I'm not copying files wholesale.
Windows uses two methods to signal a file is changed... First it sets an "Archive" flag in the item's directory entry and second it keeps a "Last Modified" date in the directory entry. Any change on a file will trigger both to be updated. Mirror checks the Archive flag to know what to copy, then resets it so it won't be copied again until the next change.
It also displays a list of files as it copies them. + means a new file, = means updated file, - means a removed file. Since it is a console program you can re-route it's output to a file, giving you a record of it's activities. I commonly use a command line something like...
Code:
mirror64 -buro \Music\*.* X:\Music >> \archivinglog.txt
The flags are ...
-B batch mode, no confirmations
-U update existing backup
-R recurse into folders
-O remove orphans
A screenshot of the help screen is attached.
Attachments
Last edited:
if you are using older hdd's (not ssd's) you may be able to recover the over written data with hdd forensics software. the first place i would look is on distrowatch.com , download and burn a live cd, make sure you have somewhere to store your files before you boot it up.
If a file has been affected by disc damage, the file system should give a read error whenever you access that file.
Flac audio files include an MD5 checksum, so the appropriate software could recurse through a disc and verify them all. Or, you could just compare them all with the AccurateRip database (Dbpoweramp's PerfectTUNES can do that), which probably takes longer and must be done on-line.
When moving or archiving files, I'll generate an md5 checksum for each folder using Corz Checksum.
Flac audio files include an MD5 checksum, so the appropriate software could recurse through a disc and verify them all. Or, you could just compare them all with the AccurateRip database (Dbpoweramp's PerfectTUNES can do that), which probably takes longer and must be done on-line.
When moving or archiving files, I'll generate an md5 checksum for each folder using Corz Checksum.
If a file has been affected by disc damage, the file system should give a read error whenever you access that file.
That is the case if the drive detects its problem (bad sector etc.). Very rarely does a bit flip on the storage happen which gets detected only by filesystems storing block checksums (ZFS, btrfs, ReFS).