Concordo. É um padrão moderno e comum.
Comprimir um arquivo duas vezes apenas desperdiça tempo e recursos.
Seria ótimo se alguém pudesse fazer esse trabalho pouco glamoroso! Não é nada brilhante, mas tornaria a vida dos que fazem auto-hospedagem muito melhor.
1 curtida
Adicionem-me à lista de pessoas que apreciariam isso, já que o tamanho dobrado das cópias de segurança faz com que elas falhem de vez em quando para mim, forçando uma limpeza manual apenas para manter as cópias de segurança funcionando.
1 curtida
Talvez pudesse ser pr-welcome?
É uma correção pequena, mas quebrar backups também é muito, muito ruim.
3 curtidas
Isso pode ser a resposta - como fazer isso? Não é uma tag disponível nesta categoria
Só alguém como Sam pode decidir o que ele aceitará como PR. Claro que nem todo PR é aquele que foi explicitamente solicitado.
1 curtida
No momento, estamos mexendo em algumas coisas relacionadas. Ainda não temos certeza se isso vai afetar diretamente este ponto, mas compartilharemos mais detalhes quando soubermos um pouco mais.
6 curtidas
Essa alteração deve eliminar o requisito de ‘2x de espaço em disco’ para os backups. Ela também distribui o custo de CPU do gz por toda a operação de backup, em vez de ser um gargalo no final:
Também estamos investigando a ideia de descartar completamente a compressão .gz do wrapper. Mas isso seria uma mudança no formato, então precisamos ter especial cautela com esse tipo de alteração.
Pessoas que usam S3 para uploads também podem se interessar por esta melhoria de desempenho, que foi implementada ontem.
6 curtidas
Obrigado… Espero que vejamos testes extensos de restauração de backups, já que essa é uma maneira bastante nova de fazer isso.
Claro!
Se algum membro da comunidade estiver interessado em ajudar com os testes, você pode usar o nome dessa branch no campo version: do YAML do seu site, fazer o redploy e então testar.
(Recomendo fazer isso em um site de staging em vez de um site de produção)
2 curtidas