Backup incremental do servidor para o AWS Glacier

Question

Estou procurando fazer backup de vários diretórios e arquivos de um servidor Linux para o AWS Glacier. Estou tentando descobrir os detalhes sobre como fazer isso.

Backups incrementais

Eu quero fazer upload de arquivos de forma incremental. Então, essencialmente, se um arquivo não mudou, eu não quero enviá-lo novamente para o Glacier se ele já existir lá. Eu acho que tenho essa parte planejada. Como você não pode obter listas instantâneas dos arquivos em seu cofre do Glacier, eu manterei um banco de dados local de arquivos enviados, para poder dizer o que existe no cofre e o que não. Isso permitirá que eu faça backups incrementais (somente o upload de arquivos ausentes ou alterados).

Não é possível sobrescrever arquivos?

De acordo com ( link ):

Archives stored in Amazon Glacier are immutable, i.e. archives can be uploaded and deleted but cannot be edited or overwritten.

Então, o que acontece se eu fizer o upload de um arquivo / arquivo e, posteriormente, o arquivo for alterado localmente e, na próxima vez que eu fizer um backup, como o Glacier lidará com isso, não poderá substituir o arquivo por uma nova?

Excluindo dados antigos

A AWS cobra US $ 0,03 por GB para excluir arquivos com menos de três meses. Como estou fazendo um backup de um servidor local, desejo excluir arquivos que não existam mais localmente. Qual é a melhor maneira de organizar isso? Use o inventário de arquivo armazenado localmente para determinar quais dados não existem mais e se é > 3 meses de idade, exclua-o da Geleira? Isso parece simples, mas existe uma abordagem melhor para isso?

Arquivos individuais vs. arquivos TAR / ZIP

Você pode fazer upload de arquivos individuais como arquivos compactados ou ser mais eficiente ao agrupar seus arquivos em arquivos TAR ou ZIP antes de fazer o upload. A ideia de arquivos TAR / ZIP é atraente porque torna mais simples e você incorre em menores taxas de armazenamento, mas estou me perguntando como lidaria com uploads incrementais. Se um arquivo zip de 20 MB for carregado e contiver 10.000 arquivos, e um desses arquivos for alterado localmente, preciso carregar outro arquivo zip de 20 MB? Agora eu sou obrigado a comer o custo de armazenar 2 cópias de quase tudo nesses arquivos zip ... Além disso, como eu iria lidar com a exclusão de coisas em um arquivo ZIP que não existem mais localmente? Como não quero excluir todo o arquivo zip, agora estou incorrendo em taxas para armazenar arquivos que não existem mais.

Talvez eu esteja pensando demais nisso. Quais são as maneiras mais diretas de abordar essas questões?

Eu não sei se isso importa ou não, mas estou usando o PHP SDK para este script de backup. Também não quero fazer o upload para um bucket S3 primeiro e depois fazer o backup do bucket para Glacier, já que agora teria que pagar também pelo S3 e pelas taxas de transferência.

    

Answer 1

So what happens if I upload a file/archive, then later, the file changes locally, and the next time I do a backup, how does Glacier deal with this since it can't overwrite the file with a new version?

De acordo com as Perguntas frequentes sobre geleiras :

You store data in Amazon Glacier as an archive. Each archive is assigned a unique archive ID that can later be used to retrieve the data. An archive can represent a single file or you may choose to combine several files to be uploaded as a single archive. You upload archives into vaults. Vaults are collections of archives that you use to organize your data.

Então, o que isso significa é que cada arquivo enviado por você recebe um ID exclusivo. Carregue o mesmo arquivo duas vezes e cada cópia do arquivo receberá seu próprio ID. Isso lhe dá a capacidade de restaurar as versões anteriores do arquivo, se desejar.

Use the locally stored archive inventory to determine what data doesn't exist anymore and if it's > 3 months old, delete it from Glacier? That seems straightforward but is there a better approach to this?

Para evitar a sobretaxa pela exclusão de dados com menos de três meses, essa é provavelmente a melhor abordagem. Mas não serão apenas os dados que não existem mais que você precisa rastrear & excluir. Como mencionado acima, sempre que um arquivo for alterado e você fizer o upload novamente para o Glacier, você receberá um novo ID para o arquivo. Você também desejará excluir as versões mais antigas do arquivo, supondo que não queira restaurar as versões mais antigas.

If a 20 MB zip file is uploaded that contains 10,000 files, and one of those files is changed locally, do I need to upload another 20 MB zip file? Now I'm required to eat the cost of storing 2 copies of almost everything in those zip files... Also, how would I deal with deleting things in a ZIP file that don't exist locally anymore? Since I don't want to delete the whole zip file, now I'm incurring fees to store files that don't exist anymore.

Essa é a troca que você realmente precisa decidir por si mesmo. Você tar / zip tudo e, em seguida, ser forçado a rastrear esses arquivos e tudo o que há neles, ou vale a pena fazer upload de arquivos individualmente para que você possa limpá-los individualmente, já que eles não são mais necessários.

Algumas outras abordagens que você pode considerar:

• Possuem dois ou mais arquivos tar / zip, um que contenha arquivos que provavelmente não serão alterados (como arquivos de sistema) e outros que contenham arquivos de configuração e outras coisas com maior probabilidade de mudar com o tempo.
• Não se preocupe em rastrear arquivos individuais e fazer backup de tudo em um único arquivo tar / zip que seja enviado para o Glacier. À medida que cada arquivo chega ao ponto de 3 meses (ou possivelmente até mais tarde), basta apagá-lo. Isso dá a você uma maneira muito fácil de rastrear & restaurar a partir de um determinado ponto no tempo.

Tendo dito tudo isso, no entanto, o Glacier pode não ser a melhor abordagem para as suas necessidades. O Glacier é realmente destinado ao arquivamento de dados, o que é diferente de apenas fazer backup de servidores. Se você quiser apenas fazer backups incrementais de um servidor, usar o S3 em vez do Glacier pode ser uma abordagem melhor. Usando uma ferramenta como Duplicidade ou rdiff- backup (em conjunto com algo como s3fs ) permitiria que você fizesse backups incrementais em um S3 balde e gerenciá-los com muita facilidade. Eu usei rdiff-backup em alguns sistemas Linux ao longo dos anos e achei que funcionou muito bem.

    

Answer 2

Aqui está a ferramenta de linha de comando para * nix, que suporta o upload de arquivos apenas modificados, substituindo arquivos modificados localmente e excluindo arquivos removidos localmente do Glacier link

    

Answer 3

Como alternativa, você poderia usar algo como Duplicidade e, em seguida, fazer o upload dos arquivos que produz.

Isso tem alguns benefícios:

• A duplicidade faz backups incrementais, portanto, apenas os arquivos alterados são capturados no conjunto de backup
• A duplicidade pode lidar com alterações de arquivo, portanto, se apenas uma pequena parte de um arquivo for modificada, em tese, somente a alteração será carregada
• Seus backups são criptografados, se você é do tipo paranóico

A maneira mais fácil de usar o Duplicity com o Glacier é:

• Faça backup em um diretório local em algum lugar (e mantenha esse backup). Duplicidade precisa de acesso ao seu arquivo "manifest" cada vez que um backup é executado, para que ele possa dizer quais arquivos foram alterados.
• Faça o upload de novos arquivos criados pelo Duplicity para o Glacier a partir do seu backup local. Use algo como glacier-cmd para isso.