Admittedly, a bit of speculation, because I can't know how all your SSH and askpass are set up, but, since that's the answer to easily 90% of crontab-related questions here:
When you run something from crontab, the environment is different than when you run it from your session. That's an architectural limitation of crontab; it just doesn't start an interactive login shell, but simply runs the specified commands as your user, which is not the same.
Paired with the fact that you're doing two user changes (through your double-sudo), my guess is that scp/ssh look into the wrong configuration files, or can't read them. Doesn't really matter: you'd really want to do this without the sshpass and without the sudo:
- This is clearly a system job – the fact that you need to become root through the use of
sudo shows that beyond doubt. So, instead of your user's crontab, this should be root's crontab. This completely removes the need for sudo. - Since you seem to control the backup server, you very clearly should not be using password authentication (since your the password as part of the command line can be read by any process, including rogue PHP scripts etc through simple things like
ps -AF as long as the backup job runs). I'd consider that password compromised now and would heavily suggest you change it immediately. Especially since you just told us one character of your password and that makes it easy for any interested party to be sure that they found the right one. Also, make sure your passwords are securely generated and not just something like "usernamePassword!" or other easy to automatically try out combination. (Guidedly) Brute forcing passwords is still a thing.
Passwordless public-key authentication for user root is really easy to set up (sudo -i -H ssh-keygen, simply press enter to accept defaults and don't specify a password; then sudo -H -i ssh-copy-id [email protected], enter password once, done). You want to do this as root, since you want these keys to be available (only!) to the root user, not your normal local user (which has no business being able to log in without knowing the password). No excuses there. - Since that reduces the amount of surprise in the environment you get, I'd personally recommend (that's a preference, so hm, heed it or not) that you'd avoid using crontabs alltogether, and just go for the easier to set up
systemd-timers. (That has a lot of advantages, as the environment is then more like an interactive session, but you also get better logging, the ability to say something like "OK, get the backup every workday at 00:13:00 +- randomized 10min and every boot just before nginx runs"). If you're interested in getting that to work and this instruction isn't helpful (and you can't find an existing answer here), do open a new question post! - Your
scp seems to be, all in all, a bad solution: it copies the whole backup, whether all files (or any) changed or not, resets the modification time (which, by the way, your nginx delivers to the clients, which means you're invalidating their caches every day, thus putting unnecessary load on your server), and isn't careful with file attributes. At the very least here, you'd use rsync instead of scp. More realistically, though:
Aside from changing your auth method, which you really must do here, and from changing the user trying to download the backup, you should probably think of this in a less "bespoke scripts that work (or don't) for you today" way, to be honest.
I've written down what I would do instead in your situation, see my answer here:
How do I automatically do daily backups and on every shutdown, and restore them elsewhere daily and on boot?
sudo some_program_that_launches_another_program sudo …makes no sense, either.commandpart of thecrontabline is, by default, interpreted by/bin/sh, which has a simpler syntax than/bin/bash, I recommend havingcommandbe a call to abashscript (executable, mounted, starts with#!/bin/bash) which sets up the environment, then calls the desired program, doing all the necessary setup and logging.sudoseems unnecessary.sudoto run this command to begin with, then this should be part of root's crontab, not yours. The secondsudois, in either case, completely useless, as you'd already be root (either by running as root throughsudoor by being root to begin with). Also, do you really mean to do a full, non-incremental backup using something slow asscpevery time? this sounds like a job forrsync, so you're not copying files you haven't changed. (or, really, a backup tool likerestic, which would come with better ways than this.)scpto keep modification times, permissions and other file attributes, using the-pflag (especially on the server from which the data originates). Really, all of this says "please don't do it usingscp, do it using something that is meant for backups". That'd be much easier, and fail-safer!