I am currently writing a script that will perform backups on a set of databases, comress them, encrypt them, transfer them to a separate storage machine, and verify that the file made it successfully. I can create the backup and perform the standard compression and encryption so that it can be safely transferred and stored in the secondary location. After this,
ssh is used to verify that a directory exists on the target machine or to force creation of that directory, then I use
scp to transfer the file, and lastly another
ssh to verify that the file exists on the other end.
This worked well in the past, however a change was made to the script to include a timestamp in the filename (in addition to the existing datestamp) and the
: characters in that timestamp in the filename are causing the transfer to fail under the
scp transfer and the following
ssh to test the file's existence.
Currently, I am creating a
DATE variable at the top of the script and setting it to the following:
$(date --date=today +%FT%H:%M:%S%z), which produces a datestamp in the proper ISO 8601 format. This works fine to create the database dumps (postgres dumps created with
pg_dump) as well as compression with
gzip and encryption with
openssl. Each of these generates a new file, with all names in the format
When the date was being provided to the filename without the time, and thus without the
: character, it worked perfectly. The specific errors I receive now that there are
: characters are on the following segments of code (
$1 refers to the argument provided to the script, containing the name of the database to be backed up, and $DATE was defined above):
scp -P PORT "$(hostname).$1-dump-$DATE.backup.gz.aes" USER@HOST:"/backups/$(hostname)/"
This fails with the error
ssh: could not resolve hostname HOSTNAME.DATABASE-dump-2015-07-31T13: Name or service not known.
ssh HOST -p PORT <<"HERE" if test -f /backups/$(hostname)/$(hostname).$1-dump-$DATE.backup.gz.aes; then echo "File exists"; else echo "Transfer failed"; fi HERE
This fails with
Pseudo-terminal will not be allocated because stdin is not a terminal. Using
-t produces the same error, and using
-t -t (from info found at stackoverflow that lead down the rabbit hole about Pseudo-terminal) does not allow the commands given after to flow through, which is probably something that I missed about what that actually does.
I would like to avoid using any additional software that would need to be installed on the machines (running Ubuntu 14.04 and latest Postgresql for DB). Please let me know if there is any way
scp/ssh can be made to handle these files properly.