ssh backup on qnap nas

Hi Stefan,

I don't think you missed something (there is no hidden magic ;D ). But I never tested with a Qnap NAS before and didn't get any response if it works out of the box yet. So maybe there are some problems with the embedded Linux which is used by Qnap.

After pressing OK backintime test all necessary commands on the remote host and normally should warn if there is something wrong.

Please run 'LC_ALL=C backintime-gnome' on command line and post the output in here.

Kind regards,
Germar

Hi,

I executed this command as follows "LC_ALL=C backintime-kde4".
The GUI started without any message in the command line.
After closing the GUI, the version number appeared in the terminal without any error messages.
I will later post the exact message.
Should I run this command as root?
By doing this some error messages appeared, maybe caused by not setting up a profile for root.
I will also post this output later on.

Please keep in mind that only one profile exists for the user "stefan".
The profile with the remote destination cannot be saved.

Thanks
Stefan

Please run the command again (or if you use root version 'kdesudo LC_ALL=C backintime-kde4') and configure your ssh-profile again. I'm hoping that there will be a helpful error message when Backintime crashes again.

'LC_ALL=C' is only to have english output. If your system language is english or german you can skip that.

Regards,
Germar

HI,

thanks for the support so far.
I forgot to add the user to the group fuse :-(.

But I am still not able to sync.
The find command on my nas has limited functionality..
You can solve this issue by installing add on products like findutils.

Is is possible to tell BIT to use on the destination (nas) the command findutils-find instead of find?
That should be the last issue to get the sync done.

In parallel I asked already on qnap side to use findutils-find as default without getting issues on the nas side.

Thanks
Stefan

The commands are 'hard-coded' at the moment. But you can either
- add 'alias find=findutils-find' in $HOME/.bashrc on your NAS (not sure if this really works)
- or you can create a PATH 'mkdir $HOME/.alias' make a symlink 'ln -s /usr/bin/findutils-find $HOME/.alias/fine' (or where ever findutils-find is located) and add 'export PATH=$HOME/.alias/:$PATH' to your $HOME/.bashrc.

If you use the remote user only for backintime this will not effect any other tasks.

Regarding your second question. Backintime check if the remote host is available before running a snapshot and will exit with a warning if not. Versions 1.0.26 and before used ping for this. Starting with 1.0.28 I use a port check on the remote host:port. If the port is open BIT will resume.

should be 'ln -s /usr/bin/findutils-find $HOME/.alias/find' not 'fine' ;)

Hi,

so I have to look more into detail how my nas is working ;-)

Most of the profile settings and environments are overwritten at boot time.
I have to change the nas boot script which is my last choice.
For me it is more important that the nas is running for all the remaining jobs :-)

So I changed the link for find in /usr/bin/find to /opt/bin/findutils-find.
instead of of /usr/bin/find to /usr/bin/busybox.
That worked so far and I was able to create my first backup via BIT over ssh on my nas.

Today I started my second backup and received the error "password-less authentication failed"
I changed nothing on my environment, all relevant keys for password-less login are still available.
The password-less authentication was working for weeks before without any issue.

To be honest, at this point in time I have no clue how to proceed.

Of course, in the next days I will start to re-new the password-less authentication.

Any ideas are welcome......

Thanks so far for answering all the questions...

Stefan

Hmm, your solution is lot more intrusive than mine because now every task on your NAS will use findutils-find instead of busybox find. This can become a serious problem if there are significant difference in those outputs. Most consumer NAS I've seen so far are controlled by quite poor scripts which will blow up if there is a change like this. (OT: my WesternDigital MyBook started deleting all my data once after I restarted syslog because of a crap php script ಠ_ಠ )

If you find a way to change find only for the user you are using for backintime I'd prefer that.

Regarding 'password-less authentication failed'. Please check:
- does it work from command line
- does 'Private key' in 'Advanced SSH Settings' point to the correct key
- is the password correct

This is the command which is used for checking password-less auth:
ssh -o PreferredAuthentications=publickey -p 22 -o ServerAliveInterval=240 <USER>@<HOST> echo "Hello"

Just keeping you up to date:

Please keep in mind that I am not very familiar using ssh.

Does it work from command line?
The password-less authentication does not work anymore on the command line too.
It changed to interactive log-in with the correct password.

does 'Private key' in 'Advanced SSH Settings' point to the correct key
How to check the advanced ssh settings? ---- I have to look for it
On the nas or the pc side?

Is the password correct?
I generated a key without pass phrase for the password less authentication
Do I have to renew it when changing the password?

ssh -o PreferredAuthentications.......
This gives me a permission denied error.
I am confused, after the interactive log-in I can access all files in the ssh directory. - This I will double check in the next days
Additionally I will review the permission in the ssh folder.

That's so far from my side

Stefan

'Advanced SSH Settings' is in Backintime Settings below Path. But that's not the problem as it doesn't work on command line either.
Please run the following commands to make sure the key has right permissions:
chown $USER:$USER -R $HOME/.ssh
chmod 700 $HOME/.ssh
chmod 600 $HOME/.ssh/id_[rd]sa
chmod 644 $HOME/.ssh/id_[rd]sa.pub

ssh <YOUR_REMOTE_USER>@<YOUR_NAS>
chown $USER:$USER -R $HOME/.ssh
chmod 700 $HOME/.ssh
chmod 600 $HOME/.ssh/authorized_keys
chmod 644 $HOME/.ssh/known_hosts
exit

If it still doesn't work after this please post the output of:
ssh -vv -o PreferredAuthentications=publickey <YOUR_REMOTE_USER>@<YOUR_NAS>

I was able to log-in password-less without any issue.

By trying out several scenarios I changed the link "find" back to busybox.
After several reboots I am now able to log-in without entering a password. ;-)

Nevertheless I changed the permission following your instruction above (thanks for that).
Additionally I changed the link "find" back to the "findutils-find" to make BIT working.

If this will happen again I will replace ssh with OpenSSH and adding a user on the nas for BIT tasks.
(The built-in ssh allows admin only to log-in)
This specific user I will assign an alias to use find-utils.

Thanks
Stefan

My nas has a built-in support for Apple's time machine.
Can I use this for connecting BIT to my nas?

If not, I will proceed as mentioned above and we can close this topic

Thanks for support

Stefan

Nope. Backintime has nothing to do with Time Machine. The idea of TM was used to create BIT but they are technically completely different.

On my qnap is now openssh running and everything is working fine.
Following this instruction
http://forum.qnap.com/viewtopic.php?f=11&t=70425
solved most of my previous issues....

But there is one remaining issue.

I created two profiles:
one profiles creates backups locally every two hours - this is working correctly
the second profile creates backups on my qnap every 12 hours - but nothing happened, if have to do this manually.
(at pc boot time the nas is normally switched off, it will be switched on later)
Any Idea to solve this one?

Stefan

Every 12 hours means it will run at 0:00 and at 12:00. If your system and your NAS isn't running at that time, it will probably never run. Recently I added a 'Daily (anacron)' schedule. This will try to run every 15min but just once every X days. But as you said your NAS is switched of at boot time, this might not help either.
You can also configure 'Custom Hours' to run that profile at times you know your system is most likely running.