No dropbox upload in backup.sh

[Funili]

I can no longer find the Dropbox Uploader in the backup.sh file.
I noticed that no more backups were saved in my Dropbox.
Will there be a replacement for this? If my Raspberry memory card is defective, a local backup cannot be used.
Greetings Funili

[Paraphraser]

Is your RPi your only computer or do you have a Mac or Windows PC as well?

If you have a Mac or PC with the Dropbox installed, you might find that IOTstackBackup solves this problem.

My "live" RPi has a cron job running iotstack_backup twice a day. The end result of each backup is files in ~/IOTstack/backups and a copy sent to my local Mac using scp. The destination folder on the Mac Is inside the Dropbox folder so the backups also get copied to the cloud.

I know the restore side of IOTstackBackup works too because I use it all the time.

[Funili]

Hi paraphrasers
That looks very good, but I still have two problems.
The first is that my NAS doesn't want to save the RSA key. But here I will still find a solution. Maybe with sshpass.
sshpass works fine!

The second is that the backup_general and backup_influxdb scripts cannot be executed by the backup script.
Here is the log file:

./iotstack_backup: line 58: iotstack_backup_general: command not found
./iotstack_backup: line 61: iotstack_backup_influxdb: command not found

When executed individually, the two scripts work as expected

My programming skills on the Raspberry are not enough to find the error ...
Greetings funili

[Paraphraser]

Some Unix basics.

Let's create a simple script:

$ cd
$ echo -e '#!/bin/bash\necho "Hello there"' >hello.sh

The "$ " is a way of telling you that you need to execute the rest of the command at the command line prompt. You don't actually type the "$", just everything else on the line.

The "cd" by itself means "move to my home directory".

When you list the file:

$ ls -l hello.sh
-rw-r--r-- 1 pi pi 31 Feb 13 20:00 hello.sh

We (the first "pi") have read and write access, members of the second "pi" group have read access, and everyone else on the computer has read access too. This is supposed to be an executable command so it needs execute permission:

$ chmod +x hello.sh
$ ls -l hello.sh
-rwxr-xr-x 1 pi pi 31 Feb 13 20:00 hello.sh

Now it's executable. Let's try running it:

$ hello.sh
-bash: hello.sh: command not found

It's right there in the current directory. The reason it isn't executable by name is because the current directory is not in the search path.

But, first, let's prove that it can be executed in the same way as you did by providing a direct path:

$ ./hello.sh
Hello there

Now let's look at the search path:

$ echo $PATH
/home/pi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

Yours might not look exactly like that but it will be similar. Let's add the current working directory to the search path:

$ PATH=$PWD:$PATH
$ echo $PATH
/home/pi:/home/pi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

Now "/home/pi" is at the front. Try typing the command without a path:

$ hello.sh
Hello there

So, that's the basic problem. You can certainly execute ./iotstack_backup but when that script tries to call iotstack_backup_general it can't find them because they are not in the search path.

Here's how you fix the problem.

$ mkdir -p ~/.local/bin

That path may already exist. This simply makes sure that it does.

Next, move to the directory where you have put iotstack_backup and all the other scripts. You need to move all of those files into ~/.local/bin.

$ mv iotstack_backup* iotstack_restore* ~/.local/bin

Now, logout, then login again. You need to do that because there is a process that runs at login time which works out if ~/.local/bin exists and, if it does, automatically adds it to your search path.

After you've logged-in again:

$ echo $PATH
/home/pi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

You can see that /home/pi/.local/bin is at the start of my PATH.

Another test is to use the "which" command:

$ which iotstack_backup
/home/pi/.local/bin/iotstack_backup
$ which iotstack_backup_general
/home/pi/.local/bin/iotstack_backup_general
$ which iotstack_backup_influxdb
/home/pi/.local/bin/iotstack_backup_influxdb

Compare that with a command that doesn't actually exist:

$ which this_command_does_not_exist
$

You just get silence.

As long as which returns a path for each of iotstack_backup, iotstack_backup_general and iotstack_backup_influxdb, you should be able to type:

$ iotstack_backup

and it will run and find the two scripts it needs to call.

I hope that all makes sense.

---

If you do all this and it still doesn't work then there might be something wrong with your .profile. Do this:

$ cat ~/.profile
$ ls -al ~

and stick the results back into your reply. I'll see if I can figure out what is going on.

[Funili]

It works!
Thank you very much for the tutoring

[Paraphraser]

We can probably call this pilot error and close it.