Backing up to the core using ssh and rync

[purps]

Hello all,

I'm trying to write a script that will backup the contents of my ubuntu machine to the core over the internal network. For example, with my music, I'm trying to do it like this...

Code: [Select]

sudo rsync -a -e ssh /data/Music/ purps@dcerouter.192.168.80.1:/mnt/device/55/public/data/audio
And I am receiving the error...

Code: [Select]

ssh: Could not resolve hostname dcerouter.192.168.80.1: Name or service not known
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(600) [sender=3.0.6]

What have I got wrong? I assume the "purps@dcerouter" bit is right; if I do a Ctrl+Alt+F2 on the core, and then login, the prompt says "purps@dcerouter". However, I was unsure about the "192.168.80.1" part. I tried DNS1 and DNS2 from the admin page, plus the gateway and external IPs, but it was to no avail. Any help would be very much appreciated, cheers.

[phenigma]

Try purps@dcerouter or purps@192.168.80.1

Trying to use the name and IP of the remotehost simultaneously will not work.  Both 'dcerouter' and 192.168.80.1 refer to the address of the core.

HTH

J.

[purps]

Thanks for the reply, that got me a little closer - using just 192.168.80.1 as the domain did the trick.

I then get asked...

Code: [Select]

purps@192.168.80.1's password:
...and I typed in the password that I used for installing Kubuntu when I set up my core (fairly sure that's the right one to use, yeah?).

However, I then get the following error...

Code: [Select]

rsync: failed to set times on "/mnt/device/55/public/data/documents/.": Operation not permitted (1)
rsync: recv_generator: mkdir "/mnt/device/55/public/data/documents/Cutie Bum's Stuff" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/mnt/device/55/public/data/documents/Humourarse" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/mnt/device/55/public/data/documents/Learning Linux -Collection of 12 Ebooks-" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: mkstemp "/mnt/device/55/public/data/documents/.Thumbs.db.KqStK5" failed: Permission denied (13)
rsync: mkstemp "/mnt/device/55/public/data/documents/.URC8206_UK.pdf.g8Wn7H" failed: Permission denied (13)
rsync: mkstemp "/mnt/device/55/public/data/documents/.bookmarks.html.whvpCk" failed: Permission denied (13)
rsync: mkstemp "/mnt/device/55/public/data/documents/.kitties.txt.BY3B7W" failed: Permission denied (13)
rsync: mkstemp "/mnt/device/55/public/data/documents/.media pc.xls.PM6OCz" failed: Permission denied (13)
rsync: mkstemp "/mnt/device/55/public/data/documents/.remote codes.WNaE8b" failed: Permission denied (13)
rsync: mkstemp "/mnt/device/55/public/data/documents/.scan0001.jpg.8vNtEO" failed: Permission denied (13)
rsync: mkstemp "/mnt/device/55/public/data/documents/.scan0002.jpg.hPygdr" failed: Permission denied (13)
rsync: recv_generator: mkdir "/mnt/device/55/public/data/documents/Uni" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: recv_generator: mkdir "/mnt/device/55/public/data/documents/job stuff" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1057) [sender=3.0.6]

Any idea what's causing this one?

Thanks again.

[phenigma]

Looks like the user 'purps' doesn't have rights to write files to those shares.

1.  I believe the correct way to do this would be to access the share through /home/public/data/documents/[share] rather than through /mnt.

2.  You may still not have write access to the shares.  Most of LMCE operates as the root user.  You may need to set a root password and use the root account for your rsync ssh login.  To set a root password you will need to become root and then run passwd to set a password.  See http://wiki.linuxmce.org/index.php/Linux_commands#becoming_root, run passwd and set the password and then use root as your user for ssh.

J.

[Lexje]

Don't forget that usernames are mapped like:
pluto_purps and the 'homedir' will be like user_1 or user_#

So if you created a user yourself, not using LMCE interface, and not adhering to LMCE philosophy, and say, later on you DID add this same user because LMCE asked you, you'll end up with 2 different users:
- purps
- pluto_purps

Off course permissions won't match accordingly.

H.T.H.

Erwin

[purps]

Thank you both for your replies. Erwin, I hear what you're saying about the mapping of the usernames.

J, I didn't try doing it through /home, as a) I have other things to backup that don't fall under documents, videos, audio, etc, so the symlinks wouldn't exist (and I know that making your own symlinks in LMCE is a no no, right?) and b) I agree with your second point, in that I don't think I would have write access using this method either (but I must stress for anybody else reading this, I didn't try it).

Either way, I set the root password on the core, and used the root account for the rsync ssh login, and it worked! So thank you, have been trying to do this for ages. I want to get a whole load of these into a script so I can back up my entire system with a single click.

Just need to work out how to embed the root password in the script, and I'm a happy bunny. Thanks again chaps.

[phenigma]

Glad it worked for you.  I'm not up enough on bash to suggest how to embed the password.  I do know that ssh won't ask for a password if you are connecting from a machine using the same username and pwd as the machine you're connecting to.

So.. if you initiate the rsync from your ubuntu machine as root user with the same password set as root on your core then I don't think it will ask for a password.

This may not help, just spouting...  Glad your backup worked!

J.

[chrisbirkinshaw]

You may find it easier to setup passwordless login (warning - only if the client is your machine!)

On the client:

1. ssh-keygen -t rsa (hit enter for all options)
2. cat .ssh/id-rsa.pub to show the key
3. Copy key to clipboard

On the server:

1. mkdir .ssh
2. nano -w .ssh/authorized_keys
3. Paste the key into the file
4. Save the file (ctrl-x) and exit

[purps]

Thanks for the replies guys.

I think I'm going to let sleeping dogs lie at this moment in time - the backup is working, and whilst I have to type in the password for each folder that gets backed up, this is OK for now, as it gives me a chance to review what is being backed up. I may try setting up the passwordless login at a later date.

Much appreciate the help. If anybody wants to see my script (it is very simple), give me a shout.

[jimbodude]

Beware - "/mnt/device/55" may not always be mounted... This is why you should access things via "/home/public/data/{storage device name}", which will trigger the auto-mounter.

[phenigma]

That's why accessing through /home/public/... is the proper way, I knew there was a reason but had forgotten about the automounter. 

J.

[purps]

Sorry, but why WOULDN'T it stay mounted? All my media is on this drive, and it's also the location for all myth recordings!

[purps]

Hang on, are you guys talking about the mounting of the drive from the point of view of the core itself, or from the point of view of the ubuntu desktop that I am backing up (i.e. mounting it as a network drive through ubuntu)?

[phenigma]

Sorry, but why WOULDN'T it stay mounted? All my media is on this drive, and it's also the location for all myth recordings!

LMCE will automatically mount and unmount shares as it needs them.  The automounter automatically unmounts filesystems that have been inactive for something like 30 seconds or more, so they disappear from /mnt/device/device_id#.  When something tries to access the files located at /home/public/data/.../Share [##]/... the automounter detects this and automatically re-mounts the filesystem for use.  I believe this action is required for media that can be unplugged (usb, network).  The automounter won't detect you accessing the share through /mnt/device/device_id# and I suppose it could try to unmount the share while you are using it. 

J.

[purps]

Right, I see. OK, I shall have another look at this tonight and see about doing it through the home folder instead.

Cheers.