Rsync with a loose nut behind the wheel

Hardware Hub Networking
,
1

Hope I’m posting in the right spot.

I’ve got an automated rsync/cron job that backs up a users home directory to a server. Both boxes are running Tumbleweed. Works great, and it was easy.

Now I want to backup various system files/directories (mostly /etc). That’s not so easy.

I CAN do that with an nfs share, but it seems horribly slow. From what I’ve read, SMB would be even slower.

From the error messeges I gather it’s an issue with security measures and SSH, particularly root access to SSH.

Any suggestions?

2

OS / File systems of all devices in use ?

3

Yes. I think. OS is linux.

4

Lots of small files? Maybe try to back up the selected items as one larger file, use Clonezilla for this and only having a large backup file send it to the destination.

2 Likes
5

^^ this confuses me.

How slow is horribly slow?

Are you SSH-ing from server into the client, and trying to do that as root?

rsync basically just instructs ssh to connect and run rsync remotely, you could configure ssh such that it ignores rsync commands and runs rsync with a particular set of flags using sudo to become root.

6

Since /etc is likely to have files only readable by root just make your life easier by having a script copying it all to tmpfs with suitable permissions and tell rsync to look for files there?

2 Likes
7

option 1: With ssh root access

  • Create ssh public key pair for all users, including the user that does backups, and add the public key to root’s authorized_keys.
  • Enable in sshd.conf :
PermitRootLogin prohibit-password
PermitRootLogin yes

option 2: Without ssh root access

  • sudo method mentioned above

option 3: Without sudo or root access

  • Run rsyncd on the machine to backup, with a module for the root filesystem:
read only = yes
address = 127.0.0.1
[backup-root]
uid = 0
path = /
hosts allow = 127.0.0.1
exclude = /dev /proc /run /sys
numeric ids = yes
auth users = backup
secrets file = /etc/rsyncd.secrets
  • Create /etc/rsyncd.secrets (backup-rsync -user:password)
  • Backup with:
export RSYNC_CONNECT_PROG='ssh backup@remote nc 127.0.0.1 873'
rsync -avAHPX rsync://backup-rsync -user@localhost/backup-root/ backup/
  • Optionally add iptables rule to only allow connecting to 127.0.0.1:873 from the backup user.

option 4: Invest in ZFS and use sanoid/syncoid :slight_smile:

2 Likes
8

zfs send/receive (would require zfs on both sides but is the best option)

9

About 25 minutes to the NFS share.

Client to server connection.

10

could you ELI5?

11

Have you performed any NFS optimizations? upped the thread count? Sparse file tree and asyncronous read/write? If you are dealing with a lot of small files, you are leaving a lot of optimizations on the table.

12

LOL. I’m only qualified for the kiddie end of the pool. I will look into, though. On a positive, I have figured out how to login as root over SSH. Seems like all my linux difficulties come down to either permissions or configs. This time it was configs, unlike when I got SSH working properly (that was perms). Still gotta get rsync handling system files. Thanks.

13

Seems like ZFS is a pretty big investment in effort. Still getting my basic linux system to run the way I want it to. Thanks.

14

Where do root’s keys go? Users have a ssl directory, but I don’t see one in the root directory. This feels like the solution I’m looking for, though. Thanks.

15

echo $HOME/.ssh/authorized_keys

Which is probably /root/.ssh/authorized_keys for the root user, but doesn’t have to be (depends on the homedir set in /etc/passwd)

16

I’ve got no /root/.ssh

Just /root/bin and /root/nfs-share. I set up the /root/nfs-share. Again, thank you.

One thing I’ve learned is most of my trouble stems from configs and perms.

There’s also a /root/inst-sys, whatever that is. It’s empty.

17

Create the folder structure. You can log into the system as root and do a key gen and that will also create all of the underlying folder structure.