bup-split - salve arquivos individuais em conjuntos de backup bup
bup split [-t] [-c] [-n name] COMMON_OPTIONS
bup split -b COMMON_OPTIONS
bup split –copy COMMON_OPTIONS
bup split –noop [-t|-b] COMMON_OPTIONS
[-r host:path] [-v] [-q] [-d seconds-since-epoch] [--bench] [--max-pack-size=bytes] [-#] [--bwlimit=bytes] [--max-pack-objects=n] [--fanout=count] [--keep-boundaries] [--git-ids | filenames...]
bup split concatena o conteúdo dos arquivos fornecidos (ou se nenhum nome de arquivo for fornecido, lê de stdin), divide o conteúdo em partes de cerca de 8k usando um algoritmo de soma de verificação contínua e salva as partes em um repositório bup. Pedaços que foram armazenados anteriormente não são armazenados novamente (isto é, eles são 'desduplicados').
Devido à maneira como a soma de verificação contínua funciona, os blocos tendem a ser muito estáveis nas alterações de um determinado arquivo, incluindo adição, exclusão e alteração de bytes.
Por exemplo, se você usar bup split para fazer backup de um dump XML de um banco de dados e o arquivo XML mudar ligeiramente de uma execução para outra, quase todos os dados ainda serão desduplicados e o tamanho de cada backup após o primeiro normalmente será ser bem pequeno.
Outra técnica é canalizar a saída dos programas tar(1) ou cpio(1) para bup split. Quando arquivos individuais no tarball mudam ligeiramente ou são adicionados ou removidos, o bup ainda processa o restante do tarball com eficiência. (Observe que salvar bup geralmente é uma maneira mais eficiente de fazer isso, no entanto.)
Para recuperar os dados, use bup-join(1).
Essas opções selecionam o comportamento primário do comando, sendo -n a escolha mais provável.
depois de criar o conjunto de dados, crie uma ramificação git chamada nome para que possa ser acessada usando esse nome. Se nome já existir, o novo conjunto de dados será considerado descendente do antigo nome. (Assim, você pode criar continuamente novos conjuntos de dados com o mesmo nome e, posteriormente, visualizar o histórico desse conjunto de dados para ver como ele mudou ao longo do tempo.) Os dados originais também estarão disponíveis como um arquivo de nível superior chamado “dados ” em o VFS, acessível via bup fuse, bup ftp, etc.
emita o ID da árvore git do conjunto de dados resultante.
emita o git commit id do conjunto de dados resultante.
emita uma série de ids git blob que correspondem aos blocos no conjunto de dados. Incompatível com -n, -t e -c.
leia os dados e divida-os em blocos com base no algoritmo de soma de verificação contínua “bupplit”, mas não armazene nada no repositório. Pode ser combinado com -b ou -t para calcular (mas não armazenar) os git blobs ou IDs de árvore para o conjunto de dados. Isso é útil principalmente para benchmarking e validação do algoritmo bupsplit. Incompatível com -n e -c.
como --noop, mas também grava os dados em stdout. Isso pode ser útil para comparar a velocidade de leitura+bupplit+gravação para grandes quantidades de dados. Incompatível com -n, -t, -c e -b.
salve o conjunto de backup no servidor remoto fornecido. Se caminho for omitido, usa o caminho padrão no servidor remoto (você ainda precisa incluir o `:'). A conexão com o servidor remoto é feita com SSH. Se você quiser especificar qual porta, usuário ou chave privada usar para a conexão SSH, recomendamos que você use o arquivo ~/.ssh/config. Mesmo que o destino seja remoto, um repositório bup local ainda é necessário.
especifique a data inscrita no commit (segundos desde 1970-01-01).
desativar mensagens de progresso.
aumentar verbosidade (pode ser usado mais de uma vez).
stdin é uma lista de IDs de objeto git em vez de dados brutos. bup split lerá o conteúdo de cada objeto git nomeado (se existir no repositório bup) e o dividirá. Isso pode ser útil para converter um repositório git com grandes arquivos binários para usar hashsplitting no estilo bup. Esta opção é provavelmente mais útil quando combinada com --keep-boundaries.
se vários nomes de arquivo forem fornecidos na linha de comando, eles normalmente serão concatenados como se todo o conteúdo viesse de um único arquivo. Ou seja, o conjunto de blobs/árvores produzido é idêntico ao que seria se houvesse um único arquivo de entrada. No entanto, se você usar --keep-boundaries, cada arquivo será dividido separadamente. Você ainda obtém apenas uma única árvore ou confirmação ou série de blobs, mas cada blob vem de apenas um dos arquivos; o final de um dos arquivos de entrada sempre encerra um blob.
imprima os tempos de referência para stderr.
nunca crie git packfiles maiores que o número de bytes fornecido. O padrão é 1 bilhão de bytes. Normalmente, não há razão para mudar isso.
nunca crie git packfiles com mais do que o número determinado de objetos. O padrão é 200 mil objetos. Normalmente, não há razão para mudar isso.
ao dividir arquivos muito grandes, tente manter o número de elementos nas árvores em uma média de numobjs.
não transmita mais de bytes/sec bytes por segundo para o servidor. Isso é bom para fazer com que seus backups não consumam toda a largura de banda da sua rede. Use um sufixo como k, M ou G para especificar múltiplos de 1024, 1024*1024, 1024*1024*1024, respectivamente.
defina o nível de compactação como # (um valor de 0 a 9, onde 9 é o mais alto e 0 é sem compactação). O padrão é 1 (compressão rápida e solta)
$ tar -cf - /etc | bup split -r myserver: -n mybackup-tar
tar: Removing leading /' from member names
Indexing objects: 100% (196/196), done.
$ bup join -r myserver: mybackup-tar | tar -tf - | wc -l
1961bup-join(1), bup-index(1), bup-save(1), bup-on(1), ssh_config(5)
Parte do pacote bup(1).
Avery Pennarun apenwarr@gmail.com.