Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SAV and TimeMachine

I installed the SAV for Mac today.

After installation, I made a local drive scan, and It found 4 threats.

I deleted the infected files.

After a while, I got alert from SAV that it denied access to the files, which had been deleted but still in my TimeMachine backup.

Although everything seems alright now, SAV interfered TimeMachine's operation.

Will this corrupt my TimeMachine backup?

:1000303


This thread was automatically locked due to age.
Parents

  • grahamperrin wrote:

    For reference (I'll tidy and interpret these later) …



     
    Using CharlesSoft TimeTracker, an apparent inconsistency after using sudo to delete some eicar test files from an early backup. I later realised that when using TimeTracker for this unusual type of troubleshooting, it's appropriate to clear caches before running the application. 
     
    TimeTracker aside for a moment: screenshot 002 is relevant. The point
    2010-11-14-125501
    where those .zip files appear, in Finder, is not the point at which they were backed up. They were backed up earlier. 
     
    Also relevant in that shot: I could copy, from that later point in the the Time Machine volume, a .zip that had been removed from an earlier point. And it was possible to extract from the .zip so this was true data (not a 'ghost' of some sort).
     
     
    Shot 002, a log of activity by SAV shows those .zip files cleaned from two points 
    2010-11-14-125501
    2010-11-14-142514
    both later than the original point of backup.
     
    Key point: those .zip files were surely backed up only once. I had made no modifications to the eicar test files. 
     
     
    Proving that Finder in Mac OS X Server 10.6.5 can not (must not) modify a Time Machine backup. I guess that Mac OS X 10.6.5 is similarly good. 
     
    Side note: these four shots were probably subsequent to a SuperDuper! attempt to restore, to the Time Machine volume, files that I had previously removed. SuperDuper! ran without error but in retrospect, I wonder whether this approach is foolproof. (A utility such as Continuum may be better suited to backing up and restoring Time Machine volumes.)
     

    Taking care to clear TimeTracker caches at appropriate points, but working with a TimeMachine backup that has been modified by my use of SuperDuper!, these 27 shots provide nothing conclusive. 

    ----

    Also noted, maybe during these experiments: 

    • if you configure Sophos Anti-Virus to delete things, and if it encounters something that can be cleaned, it will not delete that thing. 

    In terms of possible corruption, what's above probably brings nothing new/significant to this topic, but it's interesting to note in points (1) and (2) that a file backed up only once may appear at different points in the backup — if something other than Time Machine is used to modify the Time Machine volume. This persistence may be sane, there might be a good explanation somewhere around http://web.me.com/pondini/Time_Machine/Home.html if someone would like to look. 

    Underlying all of the above, an issue with the OS in Virtual Box: I later realised the clock in the guest machine sometimes lags considerably behind the clock in the host, and lags for a long time (probably until Date & Time preferences are reviewed/corrected in the guest). So don't treat these interpretations as perfect!

    :1000883
Reply

  • grahamperrin wrote:

    For reference (I'll tidy and interpret these later) …



     
    Using CharlesSoft TimeTracker, an apparent inconsistency after using sudo to delete some eicar test files from an early backup. I later realised that when using TimeTracker for this unusual type of troubleshooting, it's appropriate to clear caches before running the application. 
     
    TimeTracker aside for a moment: screenshot 002 is relevant. The point
    2010-11-14-125501
    where those .zip files appear, in Finder, is not the point at which they were backed up. They were backed up earlier. 
     
    Also relevant in that shot: I could copy, from that later point in the the Time Machine volume, a .zip that had been removed from an earlier point. And it was possible to extract from the .zip so this was true data (not a 'ghost' of some sort).
     
     
    Shot 002, a log of activity by SAV shows those .zip files cleaned from two points 
    2010-11-14-125501
    2010-11-14-142514
    both later than the original point of backup.
     
    Key point: those .zip files were surely backed up only once. I had made no modifications to the eicar test files. 
     
     
    Proving that Finder in Mac OS X Server 10.6.5 can not (must not) modify a Time Machine backup. I guess that Mac OS X 10.6.5 is similarly good. 
     
    Side note: these four shots were probably subsequent to a SuperDuper! attempt to restore, to the Time Machine volume, files that I had previously removed. SuperDuper! ran without error but in retrospect, I wonder whether this approach is foolproof. (A utility such as Continuum may be better suited to backing up and restoring Time Machine volumes.)
     

    Taking care to clear TimeTracker caches at appropriate points, but working with a TimeMachine backup that has been modified by my use of SuperDuper!, these 27 shots provide nothing conclusive. 

    ----

    Also noted, maybe during these experiments: 

    • if you configure Sophos Anti-Virus to delete things, and if it encounters something that can be cleaned, it will not delete that thing. 

    In terms of possible corruption, what's above probably brings nothing new/significant to this topic, but it's interesting to note in points (1) and (2) that a file backed up only once may appear at different points in the backup — if something other than Time Machine is used to modify the Time Machine volume. This persistence may be sane, there might be a good explanation somewhere around http://web.me.com/pondini/Time_Machine/Home.html if someone would like to look. 

    Underlying all of the above, an issue with the OS in Virtual Box: I later realised the clock in the guest machine sometimes lags considerably behind the clock in the host, and lags for a long time (probably until Date & Time preferences are reviewed/corrected in the guest). So don't treat these interpretations as perfect!

    :1000883
Children
No Data