Um aviso sobre o uso do bypasscomando para remover um backup antigo: se o backup excluído tiver pastas exatamente iguais nos backups anteriores ou posteriores, os arquivos também poderão ser excluídos dos backups anteriores ou posteriores !
O Time Machine não apenas usa links físicos para arquivos inalterados, mas também usa links físicos para pastas nas quais nenhum arquivo foi adicionado, alterado ou excluído. Isso resulta em algo como:
/2014-11-06/folder/file1
/file2
/file3
/2014-11-13/folder/file1 = hard link to file /2014-11-06/folder/file1
/file2 (changed; new inode)
/file3 = hard link to file /2014-11-06/folder/file3
/2014-11-20/folder/ = hard link to folder /2014-11-13/folder/
/2014-11-27/folder/ = hard link to folder /2014-11-20/folder/
Com o exposto acima, a exclusão de qualquer arquivo de /2014-11-06/folder/está correta e afeta apenas o backup para essa data. As contagens de referência do hard link são diminuídas, portanto, o " inode " para file2será removido, mas os inodes file1e file3ainda terão uma contagem de referência 1 devido aos backups posteriores. Portanto, rm -R /2014-11-06está bem também.
No entanto, remover qualquer arquivo de qualquer um /2014-11-13/folder/, /2014-11-20/folder/ou /2014-11-27/folder/irá efetivamente removê-lo de todas as 3 pastas.
O problema é que rm -Rnão se preocupa com pastas vinculadas. Ele apenas se repete em qualquer pasta com vínculo físico que encontra, exclui com ousadia todos os seus arquivos e remove a pasta vazia.
Portanto: ao remover um backup antigo, não se deve recursar para uma pasta vinculada e excluir seu conteúdo. Em vez disso, deve-se remover apenas o link físico da própria pasta . Então, ao invés de rm -Rusar tmutil deletecomo explicado na resposta de Arne .
Como um aparte, parece que o unlinkcomando do OS X não pode ser usado em pastas : "apenas um argumento, que não deve ser um diretório, pode ser fornecido" . A API do OS X pode remover pastas vinculadas, assim como o GNU Coreutils , como instalado usando o Homebrew .
Por fim, para provar todas as opções acima, um caso de teste (OSX 10.6.8):
sh-3.2# ls -lFa 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME staff 1551 10 30 2014 2014-11-06-012454/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME staff 1551 10 30 2014 2014-11-13-024438/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME staff 1551 10 30 2014 2014-11-20-014044/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 2 USERNAME staff 1551 10 30 2014 2014-11-27-025033/Users/USERNAME/Library/Safari/TopSites.plist
Observe que o número de links para cada ocorrência é 2 (segunda coluna). Vamos remover a primeira ocorrência:
sh-3.2# /System/Library/Extensions/TMSafetyNet.kext/Contents/MacOS/bypass unlink 2014-11-06-012454/Users/USERNAME/Library/Safari/TopSites.plist
sh-3.2# ls -lFa 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 1 USERNAME staff 1551 10 30 2014 2014-11-13-024438/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 1 USERNAME staff 1551 10 30 2014 2014-11-20-014044/Users/USERNAME/Library/Safari/TopSites.plist
-rw-r--r--@ 1 USERNAME staff 1551 10 30 2014 2014-11-27-025033/Users/USERNAME/Library/Safari/TopSites.plist
Portanto, depois de desvincular um dos arquivos, o número de links caiu para 1 para cada ocorrência, embora o arquivo ainda seja mostrado 3 vezes. Ainda não há problemas. Remova a primeira ocorrência novamente:
sh-3.2# /System/Library/Extensions/TMSafetyNet.kext/Contents/MacOS/bypass unlink 2014-11-13-024438/Users/USERNAME/Library/Safari/TopSites.plist
sh-3.2# ls -lFa 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist
ls: 2014-11*/Users/USERNAME/Library/Safari/TopSites.plist: No such file or directory
Agora tudo se foi. Aparentemente, o arquivo TopSites.plistfoi alterado pela última vez em 11/11/2014 e vinculado permanentemente em 13/11/2014, já que outros arquivos foram adicionados, alterados ou removidos na Safaripasta. Em seguida, o conteúdo da Safaripasta não foi alterado nos dois backups subsequentes; portanto, em 20/11/2014 e 27/11/2014, a Safaripasta estava vinculada ao backup anterior.
De fato, as 4 pastas usam apenas 2 inodes (primeira coluna):
sh-3.2# ls -lFaid 2014-11*/Users/USERNAME/Library/Safari/
648651968 drwxr-xr-x@ 86 USERNAME staff 2924 9 10 16:06 2014-11-06-012454/Users/USERNAME/Library/Safari//
650804457 drwxr-xr-x@ 86 USERNAME staff 2924 9 10 16:07 2014-11-13-024438/Users/USERNAME/Library/Safari//
650804457 drwxr-xr-x@ 86 USERNAME staff 2924 9 10 16:07 2014-11-20-014044/Users/USERNAME/Library/Safari//
650804457 drwxr-xr-x@ 86 USERNAME staff 2924 9 10 16:07 2014-11-27-025033/Users/USERNAME/Library/Safari//