Time Machine卡在“准备备份”上


13

我有2009年的MacBook Pro。它装有OS X 10.6(雪豹),但我升级到了10.8(Mountain Lion)。

几天前,我尝试将文件备份到外部硬盘驱动器上,就像我在操作系统升级前后成功完成了很多次一样。

屏幕顶部“时间机器”菜单上的状态显示为“正在准备备份”,而不是像通常那样递增计数。它停留了几分钟,然后我厌倦了等待并停止了备份。

昨晚,我再次尝试了一下,让它过夜放置了将近12个小时。它仍然停留在“准备备份”上。如何使备份像以前一样工作?

我尝试使用Google搜索来解决此问题,并且看到的解决方案说是等待更长的时间(没有明确的时间间隔),或者从病毒扫描程序中排除Backups.backupdb文件夹(该方法不适用于我,因为我没有有病毒扫描程序)。

在2013-5-23上编辑:这是我尝试过的所有无效的内容:

  • 我试图等待索引完成,但这似乎无济于事。我让笔记本电脑坐了约36个小时,状态仍然显示为“正在准备备份”。
  • 我在备份驱动器上找到一个名为的文件夹/Volumes/Time Machine Backups/Backups.backupdb/Elias Zamaria’s MacBook Pro (2)/2013-04-30-182726.inProgress。我删除了它,似乎没有帮助。
  • 我尝试使用“磁盘工具”验证我的主硬盘驱动器,一切似乎都很好。我尝试验证磁盘权限,但遇到一些涉及iTunes的错误(我认为),并通过单击“修复磁盘权限”按钮修复了它们。我还尝试验证我的外部硬盘驱动器,看起来还不错。我再次尝试备份,它像以前一样冻结。
  • 我尝试查看@lgsancho链接到的网站。我发现了一些看起来有用的东西,但是我还没有尝试过。
  • 我尝试运行tmutil status,但没有运行备份,却得到以下结果:

    Backup session status:
    {
        ClientID = "com.apple.backupd";
        Running = 0;
    }
    

    我开始备份,等待状态更改为“正在准备备份”,然后运行相同的命令,并得到以下结果:

    Backup session status:
    {
        BackupPhase = ThinningPreBackup;
        ClientID = "com.apple.backupd";
        DateOfStateChange = "2013-05-21 19:09:06 +0000";
        DestinationID = "8BC5795A-0AAC-4976-B960-ECCE8F48842C";
        DestinationMountPoint = "/Volumes/Time Machine Backups";
        Percent = "-1";
        Running = 1;
        Stopping = 0;
    }
    

    备份已进行约45分钟。我尝试了命令,并得到以下结果:

    Backup session status:
    {
        BackupPhase = ThinningPreBackup;
        ClientID = "com.apple.backupd";
        DateOfStateChange = "2013-05-21 19:09:06 +0000";
        DestinationID = "8BC5795A-0AAC-4976-B960-ECCE8F48842C";
        DestinationMountPoint = "/Volumes/Time Machine Backups";
        NumberOfChangedItems = 483816;
        Percent = 0;
        Running = 1;
        Stopping = 0;
    }
    

    它的外观完全相同,只是将Percent“ -1”增加到0。备份已经进行了将近3个小时。状态仍显示为“正在准备备份”,并且tmutil status得到的结果与上次完全相同。

这里是建议的事情,我不愿意尝试:

  • 清空我的垃圾。我不想这样做,因为它破坏了垃圾回收的目的,并失去了恢复我可能意外删除的文件的能力。
  • 删除旧备份。如果我认为没有其他帮助的话,可以尝试一下。

在2013-6-1上编辑:我不接受我的回答,因为它再次发生。每当重新启动时,我都会厌烦重新启动。我只是希望它停止。我正在考虑考虑删除旧备份。这是我在控制台中从备份中看到的内容:

5/31/13 11:09:09.595 PM com.apple.backupd-helper[16259]: Not starting scheduled Time Machine backup - time machine destination not resolvable.
6/1/13 12:09:37.920 AM com.apple.backupd-helper[16438]: Not starting scheduled Time Machine backup - time machine destination not resolvable.
6/1/13 12:23:20.619 AM com.apple.backupd[16473]: Starting automatic backup
6/1/13 12:23:21.794 AM com.apple.backupd[16473]: Backing up to: /Volumes/Time Machine Backups/Backups.backupdb
6/1/13 12:23:26.430 AM com.apple.backupd[16473]: Using file event preflight for Macintosh HD
6/1/13 12:23:55.148 AM com.apple.backupd[16473]: Will copy (829.8 MB) from Macintosh HD
6/1/13 12:23:55.602 AM com.apple.backupd[16473]: Found 14880 files (949.2 MB) needing backup
6/1/13 12:23:55.632 AM com.apple.backupd[16473]: 2.44 GB required (including padding), 391.84 GB available
6/1/13 9:06:02.191 AM com.apple.backupd[16473]: Cancellation timed out - exiting
6/1/13 9:10:04.406 AM com.apple.backupd[18634]: Starting automatic backup
6/1/13 9:10:05.055 AM com.apple.backupd[18634]: Backing up to: /Volumes/Time Machine Backups/Backups.backupdb
6/1/13 9:10:11.788 AM com.apple.backupd[18634]: Using file event preflight for Macintosh HD

让我们知道这里的问题是否已有您的答案。apple.stackexchange.com/questions/54216/...
bmike

不要重复使用旧的备份。使用新格式化的驱动器。
托尔比约恩Ravn的安徒生

@bmike,我查看了您链接的问题。我没有使用MacDrive或从Windows计算机访问驱动器,也没有将其用于Time Machine备份以外的任何目的。我尝试等待索引完成,但是卡住了36个小时。我尝试删除inProgress文件夹,就像建议的一种解决方案一样,它似乎没有任何作用。如果有机会,我将验证音量。
伊莱亚斯·扎马里亚

1
@EliasZamaria在更新到macOS 10.12之后,我现在遇到此问题。我已经在源和目标上验证了我的卷,并且一切都成功退出。但就我而言,percent仍为-1。您确定原因或解决方案了吗?
jsejcksn

Answers:


2

这是不正常的,但是您有两种选择:

  1. 只需等待所有处理完成或出错即可。
  2. 帮助整个过程。

在这种情况下,初始备份可能会花费很长时间,但是帮助执行此过程的方法是删除... / whatever.inProgress文件。您也可以尝试备份到新驱动器,以确保Mac相对于备份驱动器而言不是问题,而对于备份驱动器而言只是问题而已,或者只是许多需要协调的更改。

有关详细信息,请参见此其他答案。

/apple//a/65801/5472

如果您反复遇到此问题,则可以尝试隔离要备份这么长时间的文件夹。在第一次备份中,我尝试排除“用户”文件夹(如果它们具有超过10 GB的数据,则不包括引导卷底部的几个文件夹),以确保filseystem正常且备份驱动器正常。届时,您将看到每个增量备份需要一分钟左右的备份时间。然后,您可以放宽排除列表并知道它是否冻结,那么您在特定文件夹中有问题。

攻击此问题的另一种方法是运行磁盘实用程序(或其他工具)以修复目录结构或使用其他工具进行备份并擦除驱动器/从备份中还原驱动器。


我等待了将近12个小时。我必须等待多长时间?
伊莱亚斯·扎马里亚

1
下次我想尝试执行此工作时,我将尝试删除inProgress文件。
伊莱亚斯·扎马里亚

2
您还可以使用命令行工具tmutil status来准确转储您正在执行的过程。如果您要通过网络连接备份85 GB,则12个小时非常好。通过USB 5 GB将是异常的。
bmike

我找到了一个名为的文件/Volumes/Time Machine Backups/Backups.backupdb/Elias Zamaria’s MacBook Pro (2)/2013-04-30-182726.inProgress并将其移至“废纸rash”,然后像往常一样开始进行备份。我会让大家知道它的进展,并在有帮助的情况下接受此答案。
伊莱亚斯·扎马里亚

1
另请注意,“准备备份”可能需要大量的驱动器带宽-如果您可以通过电缆连接而不是无线连接,则速度可能会更快。
托尔比约恩Ravn的安德森

2

依次运行:

tmutil status

并查看NumberOfChangeItems:

$ tmutil status
Backup session status:
{
BackupPhase = ThinningPreBackup;
ClientID = "com.apple.backupd";
DateOfStateChange = "2014-12-14 16:32:00 +0000";
DestinationID = "25933E19-B889-4FAF-B421-53AFE4C68B58";
DestinationMountPoint = "/Volumes/Time Machine Backups";
NumberOfChangedItems = 92229;
Percent = 0;
Running = 1;
Stopping = 0;
}

$ tmutil status
Backup session status:
{
BackupPhase = ThinningPreBackup;
ClientID = "com.apple.backupd";
DateOfStateChange = "2014-12-14 16:32:00 +0000";
DestinationID = "25933E19-B889-4FAF-B421-53AFE4C68B58";
DestinationMountPoint = "/Volumes/Time Machine Backups";
NumberOfChangedItems = 349457;
Percent = 0;
Running = 1;
Stopping = 0;
}

只要数字在移动,您就在进步。


2
一直没有,NumberOfChangedItems但是backupd已经达到了53%的小时数
gman


0

我敢肯定,这有助于删除旧备份。我为同样的问题苦苦挣扎,并通过删除最旧的备份解决了该问题。请参阅此处的操作方法。


您确定我应该删除最早的备份而不是最新的备份吗?那有什么帮助?
伊莱亚斯·扎马里亚

0

关于Time Machine的非常有用的页面:http : //pondini.org/OSX/Home.html


1
如果您想说明该链接对当前问题的看法,那么帽子将是理想的选择。仅链接答案作为对问题的注释更好。
bmike

我在那个网站上看到了很多东西。到底有什么用?有特定页面吗?
Elias Zamaria

有关Time Machine的问题排查,您应该查看一下tankini.org/TM/Troubleshooting.html
lgsancho 2013年

有关在准备备份时卡住TM的特定帮助,请访问poolini.org/TM/D1.html
lgsancho 2013年

该链接现在已失效,因此不是很有用
Gaius

0

这可能不是OP出现此问题的原因,但是由于该问题在搜索结果中似乎很高,因此我还有另一个可能的原因:MenuMetersDisk Activity Monitor频繁轮询磁盘并完全阻止TM。

只需禁用该监视器(同时保留CPU,内存和网络监视器)即可解决此问题。


这仅与您安装了MenuMeters有关吗?
Swisher Sweet

@SwisherSweet我不知道其他软件可能也有同样的问题。但是MenuMeters当然可以阻止我的TM备份,直到我禁用它的磁盘监视器为止。
Frank Pavageau

-1

我认为这是正常现象。看到这里,第一次备份预计需要很长时间...


无论哪种方式,这对我都有效,这是一个可行的解决方案。我不知道这是否对他有用,但这是一个答案。长答案并不总是最好的。
Werner
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.