A duplicidade modifica o atime ao fazer o backup?

Question

A duplicidade modifica o atime ao fazer o backup?

#1 resposta do (0 votos)
#2 resposta do (0 votos)

0

Meus dados residem em um SSD e - graças a regravações e Amplificação de gravação - qualquer modificação de um atime resultam não apenas no inode sendo modificado, mas no bloco inteiro que ele reside ao ser apagado e reescrito. Isto é, obviamente, indesejável, pois causaria uma grande quantidade de desgaste desnecessário na unidade.

Quando o Duplicity faz o backup de arquivos, ele modifica o atributo atime dos arquivos de origem no processo?

Se ele faz modificar o atime, ele faz isso no backup inicial (completo), nos backups incrementais ou em ambos?

backup ssd duplicity atime

por Tim 30.04.2018 / 00:05

2 respostas

0

Não, é incorreto dizer que um aplicativo de software modifica o atime de um arquivo. Os programas em modo de usuário quase não têm como controlar se o atime está atualizado. Essa é a responsabilidade do sistema operacional ou, mais especificamente, do driver do sistema de arquivos . Além disso, as opções de montagem padrão atuais no Linux minimizarão as atualizações de timestamp para que elas tenham pouco impacto no desempenho ou longevidade do seu "perguntas marcadas / ssd" class="post-tag" title="show questions tagged 'ssd' "> ssd </a>. </p> <p> A situação atual das modernas distribuições <a href="/questions/tagged/linux" class="post-tag" title="show questions tagged'linux'"> linux </a> é a seguinte: </p> <ul> <li> Usando a opção de montagem <code>noatime</code> elimina completamente <code>atime</code> atualizações à custa de qualquer utilitário fornecido, mantendo <code>atime</code> metadados. </li> <li> A opção <code>relatime</code> padrão minimiza o problema </li> <li> Uma opção introduzida recentemente, <code>lazytime</code> deve eliminar completamente qualquer impacto remanescente na longevidade do SSD das atualizações de carimbo de data / hora. </li> </ul> </div> </div> <div class="action-time"> por <span title="478756" class="relativetime"> 30.10.2018 / 22:35</span> </div> </div> </div> </div> <div class="answer-pager"> </div> </div> <div class="row bottom-notice"> <p>Tags <a href="/tags/tag/backup" class="tag" title="Tag 'backup'" rel="tag">backup</a> <a href="/tags/tag/ssd" class="tag" title="Tag 'ssd'" rel="tag">ssd</a> <a href="/tags/tag/duplicity" class="tag" title="Tag 'duplicity'" rel="tag">duplicity</a> <a href="/tags/tag/atime" class="tag" title="Tag 'atime'" rel="tag">atime</a> </p> </div> <div class="row"> <a href="/questions/900099/enospc-when-space-and-inode-is-available">ENOSPC quando espaço e inode estiverem disponíveis</a> <a href="/questions/900101/how-to-update-upgrade-fedora-core-version">como atualizar / atualizar a versão do fedora core</a> </div> </div> </div> </div> </div> <footer class="footer"> <div class="container"> <div class="pull-left"> <div class="license"> user contributions licensed under <a href="https://creativecommons.org/licenses/by-sa/3.0/" rel="nofollow license">cc by-sa 3.0</a> with attribution required. </div> </div> <div class="pull-right logo"> <a href="#">  <div class="name">Sobre<span class="cl-orange">Linux</span></div> </a> </div> </div> </footer> <script src="/assets/e0fa86eb/jquery.js"></script> <script src="/assets/c14ac6f7/yii.js"></script> <script src="/js/code-prettify/prettify.js"></script> <script src="/js/site.js"></script> <script src="/assets/f4c3a820/js/bootstrap.js"></script></body> </html>

score 0 · Accepted Answer

A resposta acabou sendo sim . A duplicidade modifica o tempo de inodo de cada arquivo durante o processo de backup inicial. Isso aciona uma quantidade copiosa de SSD que reescreve e grava a amplificação.

Em backups subseqüentes (incrementais), um número muito menor (mas ainda substancial) de inodes (e arquivos alterados, é claro) é reescrito.

A duplicidade não tenta preservar o tempo dos arquivos.

Para ser justo, a maneira como o Duplicity aborda essa questão é bastante convencional e não coloca uma carga particularmente grande nos HDDs. A questão de reescrever e escrever amplificação é especificamente uma coisa SSD. Portanto, tudo o que pode ser dito sobre o Duplicity é que ele não é otimizado para SSDs e que (sendo as demais coisas iguais) você gastará SSDs mais rápido do que os HDDs se usar Duplicity.

Como Frostschutz observou nos comentários, esse problema pode ser resolvido montando seu sistema de arquivos com a configuração noatime ... para que ele possa ser mitigado com relativa facilidade.

À medida que os HDDs se extinguem e os SSDs assumem o controle, os sistemas de arquivos serão cada vez mais otimizados para SSDs e podemos esperar que o problema de desgaste / desempenho causado por alterações de atime, reescreva e grave a amplificação seja resolvido. Novos sistemas de arquivos como F2FS estão liderando pelo exemplo.