Preservar a propriedade com rsync, sem root

Conforme declarado nas outras respostas, para preservar diretamente as informações de propriedade, você precisa de acesso root à máquina de destino.

No entanto, você tinha pelo menos duas soluções alternativas para evitar o acesso root enquanto preservava a propriedade:

1. use a --fake-superopção rsync. Na página de manual:

Quando esta opção está habilitada, o rsync simula as atividades do superusuário salvando/restaurando os atributos privilegiados por meio de atributos estendidos especiais anexados a cada arquivo (conforme necessário)

Isso significa que a propriedade não é preservada diretamente no estilo clássico do Unix, em vez disso, as informações de propriedade são armazenadas dentro de um atributo estendido especial (ou seja: uma espécie de "tag" anexada ao arquivo). Ao restaurar, rsyncpode usar este EA/tag para reconstruir corretamente o proprietário do arquivo original.

2. não deixe o rsync preservar as informações de propriedade, em vez disso, preserve-as usando o getfaclutilitário. Por exemplo, ao emitir, getfacl -R MNTPOINT > acls.txtvocê salva efetivamente as informações de propriedade (e ACL) em um arquivo de texto que pode ser usado posteriormente para restaurar essas informações usando o setfacl --restorecomando.

Se eu fosse você, colocaria os backups em um volume em um contêiner do Docker. Dessa forma, você pode colocar bons limites nele e evitar riscos de segurança, mas ainda executá-lo como root para que ele faça o que precisa fazer.

Em vez de copiar todos os seus arquivos um por um como o rsync faz, você deve considerar colocar os arquivos em algum tipo de "contêiner" que permite empacotar todos os arquivos, transportá-los e nunca perder nenhum metadado.

Já pensou em "alcatrão"? Eu sei que o tar é a antítese do rsync: não é incremental, não transporta os dados para lugar nenhum, etc.

No entanto, é muito bom em preservar propriedade, permissões, ACLs, tempos de modificação e outros. Você pode fazer um arquivo tar, copiá-lo para uma máquina que nem mesmo entende a maneira Unix de fazer permissões de arquivo (ou seja, Windows, TOPS-20, VAX/VMS), depois copiá-lo de volta para um host Unix, descompactá-lo, e você obtém todas as permissões etc. que ele tinha originalmente.

Existe um sistema de arquivos FUSE que montará arquivos tar (somente leitura) .

Claro, você perde as cópias incrementais e outros recursos que tornam o rsync uma ferramenta tão excelente. No entanto, o mundo Unix usou o tar por mais de 20 anos antes do rsync ser inventado e funciona muito bem em certas situações.

Presumo que, quando você diz "sem executar o rsync como root no destino", você realmente atingiu o problema de não poder estabelecer uma conexão com o destino como root - correto? Em outras palavras - você não quer dizer literalmente "sem executar o rsync como root no destino" - mas o que REALMENTE quer dizer é "sem fazer uma conexão (automática) como root para o destino" - o que, como todos sabem, é uma tarefa difícil e perigosa coisa para fazer.

Supondo que seja esse o caso (provavelmente é), uma solução é usar canos.

A ideia é criar um canal na máquina de destino que pertence ao login não root que enviará os backups e gravar o fluxo de backup nesse canal.

Em seguida, nessa mesma máquina, você a configura para executar um processo raiz que lê o pipe e restaura o backup.

por exemplo (usando tar por exemplo) - na máquina para extrair o backup:-

mknod /tmp/pipe p
cd /folder-to-restore-into
sudo tar xfz /tmp/pipe 

E na máquina para enviar os backups de:

cd /folder-to-backup
sudo tar cfz - . | ssh [email protected] 'cat > /tmp/pipe'

Você também pode fazer o contrário (colocar o canal na outra máquina), o que pode ser útil se você quiser que o servidor de backup inicie o processo de backup (já que a máquina a ser copiada ficará bloqueada até o outro servidor lê do pipe).

Uma solução pode ser criar uma imagem de disco no local remoto e montá-la localmente:

# we assume that /mnt/backup is a mounted SHFS, SMB, etc share
truncate -s 100GiB /mnt/backup/rsync.img # create image file
mkfs.ext3 -F /mnt/backup/rsync.img # create filesystem
echo -e "o\nn\np\n1\n\n\nw" | fdisk /mnt/backup/rsync.img # create partition
mkdir /mnt/rsync 
mount -t auto -o loop /mnt/backup/rsync.img /mnt/rsync

Agora podemos executar o rsync em nossa máquina local como root:

args=(
  --recursive
  --links # copy symlinks as symlinks
  --perms # preserve permissions
  --times # preserve modification times
  --group # preserve group
  --owner # preserve owner
  --devices # preserve device files
  --specials # preserve special files
  --acls # preserve ACLs, optional check if really needed: getfacl --recursive --skip-base / 2>/dev/null | grep "file:" | cut -d" " -f3 | awk '{print "/"$1}'
  --xattrs # preserve extended attributes
  --sparse # handle sparse files efficiently
  --delete # delete extraneous files from dest dirs
  --compress # compress file data during the transfer
  --stats # give some file-transfer stats
  # --bwlimit=625 # limit transfer speed in KByte/s, 625 KB = 0.5 Mbit https://www.google.com/search?q=1+mbit+in+kbyte
  --verbose # increase verbosity
  --exclude="/dev"
  --exclude="/lost+found"
  --exclude="/media" # external mounts
  --exclude="/mnt" # external mounts
  --exclude="/proc"
  --exclude="/run"
  --exclude="/sys"
  --exclude="/tmp"
  --exclude="/var/lib/dhcp/proc" # mount to proc
  --exclude="/var/lib/named/proc" # mount to proc
  /
  /mnt/rsync
)
rsync "${args[@]}"

Obviamente, para obter os arquivos "raiz" do destino, você precisa de acesso root. No entanto, existem muitas maneiras de estragar seu sistema.

1) Você pode permitir que o rsync use sudo sem senha 2) Você pode usar setuid para rsync para que ele possa acessar arquivos root, enquanto o orquestrador de backup é um usuário normal em vez do root. 3) use rssh para limitar os riscos de segurança de todos os itens acima