How could I use rsync to backup to an old Netgear server?

English Network/Internet
#1

I have a Netgear server (model 312) that is “end of life” so I cannot get support from the Netgear site. I used it to backup using NFS in Linux Mint, but although I eventually got NFS running in Leap 15.3 the backup fails with multiple “error: Permission denied” messages, even though I have teweaked everything on the web interface for the share on the server to be as unhindered as possible. Some files do get backed up but I can’t see any difference in ownership of those that don’t get backed up (too many to be sure). Although I did struggle with the NFS configuration in Leap I am guessing that this is not a problem at the Suse end.

Older posts on the Netgear site suggest using rsync rather than NFS if there are “problems in Linux”, but the web interface starts off by asking for an “Rsync server” to set up a backup job. Have I missed something in YAST or else is there some software that would create this appearance (and handle handshakes etc.) for the Netgear server? Alternatively they suggest to push the files onto the server if there are difficulties getting to the linux machine through a firewall but I cannot connect to it; I have never used rsync so if someone could suggest how the command should look I would be grateful (it is on my LAN, not out in the clouds). I suppose setting up an ftp server on Leap might also be an alternative?

Otherwise if anyone knows this Netgear machine, is there a way to change permissions/ownership of the shares on the Netgear from a command line perhaps? But I don’t want to rework the machine.
My hard drive is 13 years old so it does need backing up!
Thanks for any advice:\

#2

Sorry, but apart from your story there isn’t much factual information. When you have those export(s)s mounted on your openSUSE system, it should be possible to show ownership/permissions of files there. Thus I guess you could at least post an

ls -l

of one file that has the permission problem and one file that hasn’t. Just to compare.

Also the entry from your /etc/fstab and the line of

mount

that shows how it is mounted.

Also, it is not clear who runs the rsync, root, another user?

#3

Right, as Henk said, more information is needed. I don’t think it’s “rsync or nfs”. rsync can use nfs as well as other protocols. So it’s important to know what protocols your Netgear device can provide: http, ftp, smb, nfs, ssh, whatever, … .

If it is providing nfs it should be possible to make it work. Which nfs version is used? Which export options?

#4

Thanks Henk and Kasi.
I thinkI panicked, imagining my hard drive failing with no recent backup (I have been using Leap for quite a few weeks now…)
Looking at the logs of the (latest as that was all that was available although there had been 10) failed backup to identify which files had not been backed up I saw that the path of the files was given as /data//… instead of /data//… . To explain, my original home directory in openSuse 10.3 was /home/. So that I could keep the 10.3 available I had it (directory in home partition) mounted on /data when I moved to Mint and /home when I booted 10.3

So here is my current fstab

~> cat /etc/fstab
/dev/system/root  /                       btrfs  defaults                      0  0
/dev/system/root  /var                    btrfs  subvol=/@/var                 0  0
/dev/system/root  /usr/local              btrfs  subvol=/@/usr/local           0  0
/dev/system/root  /tmp                    btrfs  subvol=/@/tmp                 0  0
/dev/system/root  /srv                    btrfs  subvol=/@/srv                 0  0
/dev/system/root  /root                   btrfs  subvol=/@/root                0  0
/dev/system/root  /opt                    btrfs  subvol=/@/opt                 0  0
/dev/system/root  /home                   btrfs  subvol=/@/home                0  0
/dev/system/root  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
/dev/system/root  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
/dev/system/swap  swap                    swap   defaults                      0  0
/dev/system/root  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
# /dev/sda6     /data
UUID=464d80c6-1795-4cb6-ace7-c5d6725ad3e6       /data    ext3    rw,errors=remount-ro 0       2
#entry below resulted only in data mounted according to mount command
#/data/<user>            /srv/nfs/data/<user>         none              bind                                 0  0

As you can see I have commented out the last line that I put in trying to get the nfs server working in leap; I didn’t understand it and it wasn’t working. I had never altered my fstab in Mint to backup with nfs so I took it out as one less thing to be wrong.

Now I had already put back in the subtree_check option in my /etc/exports file (because putting it in didn’t make the backup run). So it is

data/<user>   192.168.*.*/24(sync,no_root_squash,subtree_check)

Now looking at the files that failed as Henk suggested, I added a trailing slash to the path entered in the Netgear web interface so it became /data/<user>/
Now more than an hour later it has run succesfully! So because I did two things I am not surewhich one worked…
Now that the pressure is off I will make changes one at a time to improve things.
Thanks again.

#5

Glad it works. :wink: And yes!

I will make changes one at a time
I have learned that lesson long ago!:rolleyes:

#6

It mightbe that your thinking about it is correct, but you explain it a bit confusing IMO.

rsync works either local (where you do not need the rsync server) or “remote” where you work in client/sever more (rsync/rsyncd).

In the first case you can only work with files in your local directory tree. But that tree includes all mounted file systems including the NFS file systems. For rsync, as for any other program, files on a NFS file system are NOT remote, but local. They do not see any difference.

When working in client/server, it can still be the case that the server is running on the same system as the client. Again, for the client rsync that is unimportant, it works with the server rsyncd in the same way as if it was on a system at the other side of the globe.

To add to the bewildering possibilities: the server rsyncd can of course serve with all files on the system where it is running on. And those files can also be on a NFS mounted file system. Imagine all the circles you can create with all the combinations offered ;).

But rsync still works either directly with no network protocol or with the rsync protocol to the rsyncd deamon listening on port 873 by default.

#7

Ah! Thanks for explaining this Henk. I could have gone running round in circles not knowing what I am doing …
Once I have caught up with my backups etc. I want to start a parallel backup system to the server to do daily backups using rsync, so this will be very useful.

#8

Hm, I see that the fourth word of my explanation is “correct” where it should be “local”. That does not make the whole better understandable (understatement). I changed this. Nevertheless, I guess you understood the grand picture.

And indeed, when you want to backup using rsync, you can either NFS mount from one system on the other (either way around) and do a local rsync on the system where everything is available now, or run an rsyncd on one of the systems and using remote rsync from the other, again either way.

In my situation I choose for remote rsync. But that is probably only my mood at the time I organized it.
Contrary to what many would think, I made all the systems the rsync servers (running rsyncd) and the backup system the client. Again personal whim. The situation is now that when I make a backup, I only have to make sure that all systems are up and then I start the backup system (which is off to save power when not needed) and start the backup script on it. The backup system then downloads the backups from the systems one by one. When you do it the other way around, you have to start the backup run from each system. But your way of working might be very different. E.g. when the backup system is always up, you could start the backups from a crontab on the systems.

Many, many combinations are possible and correct.

One important thing belongs to a backup strategy though. You should have a disaster recovery plan and you should test it!