Sophos Free A-V For Mac May Kill Time Machine Backups 133
kdawson writes "Herewith the tale of the instantaneous loss of 19 months of Time Machine backup data, with the possible involvement of a fresh install of Sophos's new
free Mac A-V package. Sophos support has been contacted but has not responded as of this writing."
RTFA First (Score:3, Informative)
After looking through the article, while the user seems to have erred in taking Sophos and Time Machine both at their word -- I need to re-read the part he was talking about VMs, something there didn't sound right but I'm not sure what -- and been a little too quick with the OK button, it does strike me as odd that Sophos didn't drop some kind of error when it tried to write to the backup file.
Re:Sophos (Score:2, Informative)
Norton is made by Symantec, they are not separate entities. Sophos is a leading provider? Never even heard of them.
Re:Assuming this is true.... (Score:4, Informative)
combo of bad apple, bad sophos, and stupid user. (Score:2, Informative)
The closest I've ever come to AV software has been running clamav on a Slackware machine acting as a mail server, but I do understand how they work. It doesn't look like it was the AV's fault.
Well, it was in a way, AV software is a braindead solution to a problem that shouldn't exist. Use only properly signed software from trusted sources in a secure platform, that's a real solution.
Anyway, this guy killed both Sophos and the Time Machine process in the middle of a backup, while they were both trying to access his backup disk.
Backup disks should never be treated in that way, and you should actually never sync against your only copy of a backup. That is plain stupidity. Backups should be done in two stages:
Active Data -> Backup server -> Offline backup.
Connecting your only copy of your backup to where your precious data is means you have both copies of your information connected and mounted in a single computer. That's beyond stupid.
Anyway, it seems like Apple's fault. I've used Rsync for ages. You can kill an rsync process, and recover from where you started, but I can see how cheaper backup alternatives might screw everything up if you killed them in the middle of an operation.
I don't know how data is stored on TM's timecapsules, but it doesn't seem to be transactional or secure, based on the way this guy lost so much data in a split second.
I guess my policy of staying away of anything proprietary, and using server-class, proven backup solutions in the proper way (data -> backup server -> offline storage), using fully transactional solutions, and always backing up to separate instances on the second stage (instead of replacing) is the only solution, as I've never lost a byte, while I keep hearing terrible stories of data loss, empty backups and massive filesystem corruption (yeah, mostly from windows/mac users).
Re:Assuming this is true.... (Score:5, Informative)
No, it's separate files. You can browse it using finder or terminal.
Unless you're backing up a filevault protected home directory. Then it handles it in just about the stupidest way possible: it saves the whole honking encrypted image as one big file.* And despite the fact that it doesn't decrypt the image, it still only works if you're logged in and the image is open.
*If you're set up as sparse images, then you do a little better. But still, no incremental backups for you. If a file changes, you have to copy the *whole* thing, because good encryption won't make it obvious which bits of the file are different. Also, I'm not sure it can tell which files are, say, disk cache for the browser....
Re:Assuming this is true.... (Score:4, Informative)
FYI, I'm not using filevault, just individual files to be backed up... but TM uses sparsebundles in ways I don't begin to understand. One respondent via Twitter suggested that Sophos may have simply been in the process of deleting the entire sparsebundle -- i.e. the entire lot of backups -- when I killed its process. No idea if this is correct. I hope Sophos eventually provides some insight.
Re:Assuming this is true.... (Score:4, Informative)
yes, one large file which is actually a sparse disk image.
it's a sparse disk image bundle thingy. Which uses a bunch of 8MB files, not one file. from the hdiutil man page [apple.com]:
By default, UDSP images grow one megabyte at a time.
Introduced in 10.5, UDSB images use 8 MB band files
which grow as they are written to.. -imagekey
sparse-band-size=size can be used to specify the
number of 512-byte sectors that will be added each
time the image grows. Valid values for SPARSEBUNDLE
range from 2048 to 262144 sectors (1 MB to 128 MB).
The maximum size of a SPARSE image is 128 petabytes;
the maximum for SPARSEBUNDLE is just under 8
exabytes (2^63 - 512 bytes minus 1 byte). The
amount of data that can be stored in either type of
sparse image is additionally bounded by the filesys-
tem in the image and by any partition map. compact
can reclaim unused bands in sparse images backing
HFS+ filesystems. resize will only change the vir-
tual size of a sparse image. See also USING PERSIS-
TENT SPARSE IMAGES below.
Re:Assuming this is true.... (Score:5, Informative)
One thing. directly connected hard drives do not use sparse bundles if FileVault is not on,.
I am actually not surprised (Score:4, Informative)
The time machine stores the back up files on an external hard drive in a specific way such that can perform the backup task and the possible restore task effectively. In order to this to work noone should modify or delete any data stored in the backup location. This will most likely corrupt the backup.
The author of the article told Sophos AV to delete files from within the time machnien backup location ... well, of course one can expect that it messes things up.