1 2 3 4 5 Previous Next 174 Replies Latest reply: Feb 18, 2014 8:41 AM by bernuli Go to original post
  • 30. Re: Time Machine always requires deep traversal?
    Stephen Bash Level 1 Level 1 (5 points)

    Still no answers, but a little more digging shows most of the Time Machine metadata is stored in the extended file attributes on the backup volume (was writing this when Pondini replied! Thanks!):

     

    $ xattr -l /Volumes/Time\ Machine\ Backups/Backups.backupdb/warp/2012-07-13-165249
    com.apple.backup.SnapshotNumber:
    00000000  32 32 30 36 00                                   |2206.|
    00000005
    com.apple.backup.SnapshotVersion:
    00000000  31 00                                            |1.|
    00000002
    com.apple.backupd.SnapshotCompletionDate:
    00000000  31 33 34 32 32 31 32 37 36 39 32 32 36 30 30 36  |1342212769226006|
    00000010  00                                               |.|
    00000011
    com.apple.backupd.SnapshotStartDate:
    00000000  31 33 34 32 32 31 32 30 39 35 36 34 31 38 36 35  |1342212095641865|
    00000010  00                                               |.|
    00000011
    com.apple.backupd.SnapshotState:
    00000000  34 00                                            |4.|
    00000002
    com.apple.backupd.SnapshotType:
    00000000  31 00                                            |1.|
    00000002
    $
    

     

    I can confirm the SnapshotCompletionDate is the exact value that shows up in the backup log as "Date of Previous snapshot".  But what I'm really interested in is the last FSEvent ID, which is stored the next level down:

     

    $ xattr -l /Volumes/Time\ Machine\ Backups/Backups.backupdb/warp/2012-07-13-165249/Snow\ Leopard/
    com.apple.backupd.SnapshotVolumeLastFSEventID:
    00000000  31 38 31 35 38 36 34 31 37 34 33 32 32 31 34 32  |1815864174322142|
    00000010  35 32 37 33 00                                   |5273.|
    00000015
    $
    

     

    To my surprise, that FSEvent ID looks valid (i.e. not 2^63-1; FWIW the most recent events as of this morning are about 18158641743223610342).  So I guess something in the TM logic is creating the "bad" 2^63-1 number.  For the gory details, here's dtruss running on backupd as in the region of interest:

     

    open("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-16-090407.inProgress/.dat45aa.003\0", 0xA02, 0x1B6)   = 4 0
    close(0x4)   = 0 0
    rename("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-16-090407.inProgress/.dat45aa.003\0", "/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-16-090407.inProgress/.Backup.364137318.114736.log\0" = 0 0
    chmod(0x1006EFDB0, 0x180, 0x0)   = 0 0
    open("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-16-090407.inProgress/.Backup.364137318.114736.log\0", 0x1, 0x0)   = 4 0
    fstat64(0x4, 0x1006EFDF0, 0x0)   = 0 0
    write(0x4, "2012-07-16-09:15:18 - Starting backup\n\nPrevious snapshot:\n\t/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249\n\n\0", 0x82)   = 130 0
    write(0x4, "Date of Previous snapshot: 1342212769226006\n\n\0", 0x2D)   = 45 0
    getdirentriesattr(0x5, 0x1006E4EA0, 0x102000000)   = 1 0
    geteuid(0x1006EB620, 0x1006EBBD8, 0x0)   = 0 0
    close(0x5)   = 0 0
    lstat64("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/.Backup.log\0", 0x1006F0120, 0xFC080)   = 0 0
    lstat64("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/.exclusions.plist\0", 0x1006F0120, 0x7FFF71289650)   = 0 0
    lstat64("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/Snow Leopard\0", 0x1006F0120, 0x7FFF71289650)   = 0 0
    getxattr("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/Snow Leopard\0", 0x10017CB00, 0x0)   = 37 0
    getxattr("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/Snow Leopard\0", 0x10017CB00, 0x10017C630)   = 37 0
    lstat64("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/Snow Leopard\0", 0x1006F02B0, 0x7FFF71289650)   = 0 0
    lstat64("/private/var/db/.TimeMachine.NeedsFullScan\0", 0x1006F0300, 0xFC080)   = -1 Err#2
    getxattr("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/Snow Leopard\0", 0x10017D060, 0x0)   = 21 0
    getxattr("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/Snow Leopard\0", 0x10017D060, 0x10017CDA0)   = 21 0
    getxattr("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/Snow Leopard\0", 0x10017D340, 0x0)   = 37 0
    getxattr("/Volumes/Time Machine Backups/Backups.backupdb/warp/2012-07-13-165249/Snow Leopard\0", 0x10017D340, 0x10017CD70)   = 37 0
    geteuid(0x7FFF709E8260, 0x0, 0x0)   = 0 0
    write(0x4, "Gathering events since 9223372036854775807.\n\0", 0x2C)   = 44 0
    

     

    I can confirm the /private/var/db/.TimeMachine.NeedsFullScan file does not exist on my system.  Based on the sizes the last few getxattr calls are requesting the SnapshotVolumeLastFSEventID and SnapshotVolumeFSEventStoreUUID respectively (first with a NULL target to get the size, and then with a correctly sized buffer passed as the target).  I have the full dtruss output, but prior to this TM just appears to be looking through the backup volume for snapshots.

     

    Stephen

  • 31. Re: Time Machine always requires deep traversal?
    Pondini Level 8 Level 8 (38,720 points)

    Stephen Bash wrote:

    . . .

    Based on the sizes the last few getxattr calls are requesting the SnapshotVolumeLastFSEventID and SnapshotVolumeFSEventStoreUUID respectively

    . . .

    prior to this TM just appears to be looking through the backup volume for snapshots.

    Is it really looking at all the snapshots?  I'd expect it to only look at the last one (probably via the Latest alias).

     

    Is (or was) the snapshot it's getting the Event ID and UUID from the last one?

     

    Have you tried another external HD?  It almost sounds like something is going on with that drive that's returning a false/invalid value for the Event ID and/or UUID, in a way that TM doesn't seem to realize is wonky.  An extremely long shot, but we're in extremely weird territory here. 

  • 32. Re: Time Machine always requires deep traversal?
    Stephen Bash Level 1 Level 1 (5 points)

    Pondini wrote:

     

    Is it really looking at all the snapshots?  I'd expect it to only look at the last one (probably via the Latest alias).

     

    Yes, it scans ALL the snapshots (or at least stat's all of the directories), but I don't think it recurses into any of them.

     

    Pondini wrote:

     

    Is (or was) the snapshot it's getting the Event ID and UUID from the last one?

     

    Yes, I've had TM turned off a lot recently due to the issues and it correctly found the most recent backup and queried it.

     

    Pondini wrote:

     

    Have you tried another external HD?  It almost sounds like something is going on with that drive that's returning a false/invalid value for the Event ID and/or UUID, in a way that TM doesn't seem to realize is wonky.  An extremely long shot, but we're in extremely weird territory here. 

     

    I'm currently creating a new partition on the existing drive to emulate wiping the drive (my plan is to unmount the original and reinitialize TM on the new partition).  If that still behaves badly (which it might), I'm going to attempt to scrounge another external drive for testing.

     

    And yes, we're very much in the weeds at this point...

     

    Thanks,

    Stephen

  • 33. Re: Time Machine always requires deep traversal?
    Pondini Level 8 Level 8 (38,720 points)

    Stephen Bash wrote:

    . . .

    And yes, we're very much in the weeds at this point...

    Weeds, I'm used to.

     

    This is more like the Okefenokee swamp. 

  • 34. Re: Time Machine always requires deep traversal?
    Stephen Bash Level 1 Level 1 (5 points)

    Pondini wrote:

     

    Stephen Bash wrote:

    . . .

    And yes, we're very much in the weeds at this point...

    Weeds, I'm used to.

     

    This is more like the Okefenokee swamp. 

     

    Ha! Seems that way.

     

    Well, the initial backup on the new partition just finished, and even before the first hourly backup runs I have some interesting data:

     

    2012-07-16-13:27:51 - Starting backup
    
    Previous snapshot:
            None
    
    Will traverse "Snow Leopard" (mount: '/' fsUUID: ... eventDBUUID: ...)
    === Starting backup loop #1 ===
      Will use FirstBackupCopier
    
    
    ... snip...
    
    Finished copying items for "Snow Leopard" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Time elapsed: 1 hour, 37 minutes, 27.000 seconds
            Copied 440896 items (85.6 GB)
    Gathering events since 9223372036854775807.
    Needs new backup due to change in /
    === Starting backup loop #2 ===
      Will use IncrementalBackupCopier
    
    ... snip ...
    
    Finished copying items for "Snow Leopard" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Time elapsed: 2 minutes, 51.000 seconds
            Copied 20517 items (320.0 MB)
    Gathering events since 9223372036854775807.
    Needs new backup due to change in /
    Some filesystem changes made during the course of the backup may not be accounted for. Still busy after 2 retries.
    Finalizing completed snapshot
    Finished finalizing completed snapshot
    
    Backup complete.
    Total time elapsed: 1 hour, 49 minutes, 57.000 seconds
    

     

    So that cursed 2^63-1 event ID is still floating around.  I'll let the first hourly go through just in case, but I'm guessing the behavior won't change.  Then I'll try a different external disk.  Perhaps a logical extension would be to initialize a new internal HD from one of my backups and see if the behavior persists across that (or even just a clean system perhaps).  But that's getting into major time sink land...

     

    Stephen

  • 35. Re: Time Machine always requires deep traversal?
    Pondini Level 8 Level 8 (38,720 points)

    Stephen Bash wrote:

    . . .

    So that cursed 2^63-1 event ID is still floating around.  I'll let the first hourly go through just in case, but I'm guessing the behavior won't change.

    Yeah, doubtful.

     

    Then I'll try a different external disk.

    Worth a shot.

     

    I don't see anything in the earlier posts about installing the "combo" update and/or a fresh version of OSX, per Installing the ''combo'' update and/or Reinstalling OSX.  If you haven't done that yet, that's also worth a try.  If something is bunged up in your version of Snow Leopard, all sorts of bizarre things may occur.

  • 36. Re: Time Machine always requires deep traversal?
    Stephen Bash Level 1 Level 1 (5 points)

    Pondini wrote:

     

    Stephen Bash wrote:

    . . .

    So that cursed 2^63-1 event ID is still floating around.  I'll let the first hourly go through just in case, but I'm guessing the behavior won't change.

    Yeah, doubtful.

     

    Yep, problem persisted.

     

    Pondini wrote:

    Then I'll try a different external disk.

     

    Worth a shot.

     

    No joy there either.

     

    Pondini wrote:

     

    I don't see anything in the earlier posts about installing the "combo" update and/or a fresh version of OSX, per Installing the ''combo'' update and/or Reinstalling OSX.  If you haven't done that yet, that's also worth a try.  If something is bunged up in your version of Snow Leopard, all sorts of bizarre things may occur.

     

    Downloading now...

     

    Thanks,

    Stephen

  • 37. Re: Time Machine always requires deep traversal?
    Stephen Bash Level 1 Level 1 (5 points)

    Stephen Bash wrote:

    Pondini wrote:

     

    I don't see anything in the earlier posts about installing the "combo" update and/or a fresh version of OSX, per Installing the ''combo'' update and/or Reinstalling OSX.  If you haven't done that yet, that's also worth a try.  If something is bunged up in your version of Snow Leopard, all sorts of bizarre things may occur.

     

    Downloading now...

     

    Combo Update didn't change anything; TM's log still identifies 2^63-1 as the last event ID.

     

    Reinstalling OS X gets interesting.  This particular machine came with a 10.7 install disk (hence I still have a Lion partition floating around), while the 10.6 partition (my main platform) came from this process.  That could be the crux of the problem, but I was (still am?) hoping that's not the case.  To test that theory I could image a new partition with the same image and see if TM is broken there or not (the image is just the bare system, no development tools or common applications)...  I'll have to think about it.

     

    Thanks,

    Stephen

  • 38. Re: Time Machine always requires deep traversal?
    Pondini Level 8 Level 8 (38,720 points)

    Stephen Bash wrote:

    . . .

    This particular machine came with a 10.7 install disk (hence I still have a Lion partition floating around), while the 10.6 partition (my main platform) came from this process.  That could be the crux of the problem,

    Yes, it cerainly could. 

     

    What's on your Lion partition?  What happens when you boot into it and back it up (preferably to a different disk or partition than your current backups)?

  • 39. Re: Time Machine always requires deep traversal?
    Stephen Bash Level 1 Level 1 (5 points)

    Pondini wrote:

     

    Stephen Bash wrote:

    . . .

    This particular machine came with a 10.7 install disk (hence I still have a Lion partition floating around), while the 10.6 partition (my main platform) came from this process.  That could be the crux of the problem,

    Yes, it cerainly could. 

     

    Doesn't look like it's directly related.  I was able to image a new partition (nice aspect of the process is imaging goes fast), and doing an initial backup the second pass did not require the deep traversal.  To my surprise though, the log still has the 2^63-1 event ID, so that may actually be a red herring:

     

    2012-07-17-13:40:15 - Starting backup
    
    Previous snapshot:
              None
    
    Will traverse "TM Test" (mount: '/' fsUUID: ... eventDBUUID: ...)
    === Starting backup loop #1 ===
      Will use FirstBackupCopier
    
    Running preflight for "TM Test" (mount: '/' fsUUID: ... eventDBUUID: ...)
              Excluding /.Spotlight-V100: 25.9 MB (54 items)
              Excluding /.Trashes: 0 bytes (0 items)
              Excluding /.fseventsd: 12 KB (3 items)
              Excluding /.hotfiles.btree: 64 KB (0 items)
              Excluding /private/var/db/Spotlight: 36.2 MB (2 items)
              Excluding /Volumes: 4 KB (8 items)
              Excluding /Network: 0 bytes (0 items)
              Excluding /.vol: 0 bytes (0 items)
              Excluding /cores: 0 bytes (0 items)
              Excluding /private/tmp: 4 KB (6 items)
              Excluding /private/tftpboot: 0 bytes (0 items)
              Excluding /private/var/folders: 240.4 MB (74 items)
              Excluding /private/var/run: 40 KB (13 items)
              Excluding /private/var/tmp: 0 bytes (1 items)
              Excluding /private/var/vm: 64.0 MB (1 items)
              Excluding /private/var/db/dhcpclient: 4 KB (2 items)
              Excluding /Library/Caches: 68 KB (5 items)
              Excluding /Library/Logs: 12 KB (3 items)
              Excluding /System/Library/Caches: 17.2 MB (23 items)
              Excluding /private/var/log: 132 KB (33 items)
              Excluding /private/var/spool/cups: 0 bytes (3 items)
              Excluding /private/var/spool/fax: 0 bytes (0 items)
              Excluding /private/var/spool/uucp: 0 bytes (0 items)
              Excluding /private/var/db/dyld: 610.9 MB (13 items)
              Excluding /Users/bash/Library/Calendars/Calendar Cache: 112 KB (1 items)
              Should copy 392422 items (5.9 GB) representing 1542420 blocks of size 4096. 121911221 blocks available.
    Preflight complete for "TM Test" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Time elapsed: 0.340 seconds
    
    Processing preflight info
              Space needed for this backup: 7.1 GB (1851027 blocks of size 4096)
    Finished processing preflight info
    
    Copying items from "TM Test" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Finished copying items for "TM Test" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Time elapsed: 14 minutes, 2.000 seconds
              Copied 123885 items (5.9 GB)
    Gathering events since 9223372036854775807.
    Needs new backup due to change in /
    === Starting backup loop #2 ===
      Will use IncrementalBackupCopier
    
    Running preflight for "TM Test" (mount: '/' fsUUID: ... eventDBUUID: ...)
              Calculating size of changes
              Should copy 74 items (8 KB) representing 2 blocks of size 4096. 120314246 blocks available.
    Preflight complete for "TM Test" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Time elapsed: 3.483 seconds
    
    Processing preflight info
              Space needed for this backup: 334.9 MB (85722 blocks of size 4096)
              Preserving last snapshot /Volumes/TM Test Backup/Backups.backupdb/...
    Finished processing preflight info
    
    Copying items from "TM Test" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Finished copying items for "TM Test" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Time elapsed: 8.027 seconds
              Copied 926 items (9 KB)
    Gathering events since 9223372036854775807.
    Needs new backup due to change in /
    Some filesystem changes made during the course of the backup may not be accounted for. Still busy after 2 retries.
    Finalizing completed snapshot
    Finished finalizing completed snapshot
    
    Backup complete.
    Total time elapsed: 14 minutes, 15.000 seconds
    

     

    Pondini wrote:

     

    What's on your Lion partition?  What happens when you boot into it and back it up (preferably to a different disk or partition than your current backups)?

     

    If I get a chance, I'll give it a try...  I think I've been messing around enough this afternoon already

  • 40. Re: Time Machine always requires deep traversal?
    blazetopher Level 1 Level 1 (0 points)

    Hi all,

     

    I've been encountering the same issues for quite some time now (the bizzare 2^63-1 event ID, very slow incremental backups of 1000's of very small files - even when the comp has been idle, etc) - to the extent that I stopped backing up for a while(boo...).

     

    Last week I spent the time to start from scratch: format, reinstall, update (combo installer), reload apps.  The first backup (with a freshly reformatted external) went as expected: ~2.5 hrs for 70GB.  But the incrementals since then have had the exact same issues as before.

     

    I'm running 10.6.8 on a MacBookPro6,1

     

    Has anyone had any luck resolving these issues?  Happy to post any/all logs.

     

    Thanks,

    Chris

  • 41. Re: Time Machine always requires deep traversal?
    Pondini Level 8 Level 8 (38,720 points)

    blazetopher wrote:

    . . .

    I've been encountering the same issues for quite some time now (the bizzare 2^63-1 event ID, very slow incremental backups of 1000's of very small files - even when the comp has been idle, etc) - to the extent that I stopped backing up for a while(boo...).

    Please post the log from one of those backups (the widget in #A1 of Time Machine - Troubleshooting would be fine).

     

    If the file counts are in the tens of thousands, you may be having a problem we've seen with a few folks on 10.6.8.   

     

    Some of them fixed it by installing a fresh copy of Snow Leopard, but only gong back to 10.6.7 via the combo update, not 10.6.8.  (see Installing the ''combo'' update and/or Reinstalling OSX for the link).

     

    (If you do that, be aware of the bug explained in the 3rd item of #D5 in Time Machine - Troubleshooting.

  • 42. Re: Time Machine always requires deep traversal?
    blazetopher Level 1 Level 1 (0 points)

    Hi Pondini, thanks for the quick reply.

     

    The file counts are definitely in the 10's of thousands.  I've been waiting for the latest backup to finish before posting the log, but got sick of waiting (>2 hrs) for "Finishing Backup", and ended up just stopping it...

     

    Second to last backup (took 6 hours 20 minutes to complete):

    Starting standard backup

    Backing up to: /Volumes/DEV014MAC001_TM/Backups.backupdb

    No pre-backup thinning needed: 974.6 MB requested (including padding), 637.42 GB available

    Copied 54 KB of 54 KB, 470719 of 470719 items

    Copied 601922 files (145 KB) from volume Macintosh HD.

    No pre-backup thinning needed: 984.2 MB requested (including padding), 637.14 GB available

    Copied 44 KB of 44 KB, 41582 of 41582 items

    Copied 52 KB of 52 KB, 495241 of 495241 items

    Copied 601922 files (129 KB) from volume Macintosh HD.

    Starting post-backup thinning

    Backup completed successfully.

    Stopping backupd to allow ejection of backup destination disk!

     

    Latest backup (took 5 hours 58 minutes prior to my stopping during "Finishing Backup"):

    Starting standard backup

    Backing up to: /Volumes/DEV014MAC001_TM/Backups.backupdb

    No pre-backup thinning needed: 4.07 GB requested (including padding), 636.89 GB available

    Copied 1.6 GB of 2.6 GB, 62310 of 62310 items

    Copied 1.6 GB of 2.6 GB, 504430 of 504430 items

    Copied 616753 files (2.0 GB) from volume Macintosh HD.

    No pre-backup thinning needed: 1.13 GB requested (including padding), 634.64 GB available

    Copied 2.6 MB of 23.4 MB, 103101 of 103101 items

    Copied 2.6 MB of 23.4 MB, 560767 of 560767 items

    Copied 607607 files (31.1 MB) from volume Macintosh HD.

    Backup deletion was canceled by user

    Starting post-backup thinning

    Backup completed successfully.

     

    These "incrementals" are taking so long that the next backup starts immediately after the previous one ends - so the machine (and drive) are ALWAYS cranking....

     

    I guess I can try installing the 10.6.7 update.  Do I need to reinstall from scratch in order to do so, or can I install "on top" of the current 10.6.8 (effectively a rollback)??  To be frank, I don't have time to do the full reinstall again as this is my work computer and I won't have a free day to do it for quite some time...

     

    Or would it be sufficient to reinstall from my disk (NOT wiping the drive first) and then applying the 10.6.7 combo update?

     

    Did either other folks on this thread find any solutions (if you're still listening)?

     

    Thanks again,

    Chris

  • 43. Re: Time Machine always requires deep traversal?
    Pondini Level 8 Level 8 (38,720 points)

    blazetopher wrote:

    . . .

    Or would it be sufficient to reinstall from my disk (NOT wiping the drive first) and then applying the 10.6.7 combo update?

    Yes, that's the recommendation (no reason to erase everything).  It has solved this problem for a few folks.

     

    Why the problem happens to only a few, and why going back to 10.6.7 fixes it for some, we don't know.  It seems to be the combination of 10.6.8 and something else. 

  • 44. Re: Time Machine always requires deep traversal?
    Stephen Bash Level 1 Level 1 (5 points)

    blazetopher wrote:

     

    Did either other folks on this thread find any solutions (if you're still listening)?

     

    I'm still kicking around (and subscribed to updates on this thread).  I haven't found a solution yet other turning off automatic backups and manually kicking one off once or twice a day.  If the 10.6.7 update works for you, I'd like to know.  I reinstalled the 10.6.8 combo update but wasn't sure about downgrading my main work computer...

    blazetopher wrote:

     

    The file counts are definitely in the 10's of thousands.

     

    This made me curious, so I checked some of my logs on the TM volume itself (/Volumes/Backups/Backups.backupdb/warp/2012-07-17-005335/.Backup.log):

     

    Running preflight for "Snow Leopard" (mount: '/' fsUUID: ... eventDBUUID: ...)
            Scanning nodes needing deep traversal
            Node requires deep traversal: / reason:contains changes|must scan subdirs|fsevent|
            Calculating size of changes
            Should copy 889 items (18.1 MB) representing 4627 blocks of size 4096. 220574366 blocks available.
    Preflight complete for "Snow Leopard" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Time elapsed: 2 minutes, 46.000 seconds
    
    Processing preflight info
            Space needed for this backup: 1.2 GB (321635 blocks of size 4096)
            Preserving last snapshot /Volumes/Backups/Backups.backupdb/warp/2012-07-16-235334
    Finished processing preflight info
    
    Copying items from "Snow Leopard" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Finished copying items for "Snow Leopard" (mount: '/' fsUUID: ... eventDBUUID: ...)
    Time elapsed: 2 minutes
            Copied 20501 items (18.2 MB)
    

     

    And there's a major disconnect between what preflight thinks it should back up and what is actually copied (889 vs 20501)...  I don't know if that's normal or not.

     

    Thanks,

    Stephen

1 2 3 4 5 Previous Next