Encrypt and backup folder to email daily, when online

I have a backup script which should backup a folder and send it to email. This should be done once a day. As this is on my laptop which is not online 24/7 I need to check that I am online and can send email. For this script I have an entry in crontab running every 2 hours.

Because the folder is a really important to me and I am quite new to BASH, I would like to ask you if there are any weak points in my code:

#!/usr/bin/env bash

cd ~/projects

DATE=`date +%Y%m%d`
PASS="mysecretpasswordiwontwritehere"
# lastbackup file stores date of last backup in YYYYMMDD format
LASTBACKUP=$( $DATE.enc

# Send email
MTO="mybackupemail@gmail.com"
MSUB="PW backup as on $DATE"
MATT="$DATE.enc"
EMAIL="backuprobot@mymachine.com" mutt -s "$MSUB" -a $MATT -- $MTO  ./personalwiki/lastbackup

This is an incomplete answer; I'd just like to contribute more comments than easily fit in an actual comment.

-
Consider replacing PASS="mysecretpasswordiwontwritehere" with PASS=cat mysecretpassword.file` and moving your password into that file. Then you don't have to worry about always remembering to hide it when sharing your source code (or when editing/debugging it).

-
For the test whether the laptop is online, consider being more specific, such as pinging the actual hostname you need to be up (gmail.com rather than www.google.com). Logging (repeated) failure could be a good idea. Beware of the possibility that Google might decide to disable ICMP ping responses (without stopping email processing). If you want to improve further, you may want to look into testing if the service you use for email submission (SMTP/IMAP/whatever) is up. Maybe (I am guessing) there is an option to let mutt do that for you, such that you aren't effectively doubling email configuration? I'm guessing because I barely know mutt.

-
Beware that your tar invocation depends on the environment variable TAPE not being set. Unless you're willing to write its sensitive output into a temporary file, specifying /dev/stdout may be the only alternative, though.

-
You are not logging any other failures, at least not beyond relying on whatever cron is configured to do for you. If tar or openssl somehow aborts, you may be much better off aborting (and logging that there was an error) rather than continuing to the point of logging the date of the completed backup. Likewise in case mutt fails, but that is more complicated since your code may(?) start an asynchronous email transfer. For the rest, you can re-use your code for aborting upon ping failure to detect other errors, ideally logging and aborting (use e.g. exit 1 rather than exit 0 for errors).

-
Beware that aspects on how this works or fails depend on how cron` is configured. Don't accidentally make the mistake of having it run as root rather than under your user account, for example.

StackExchange Code Review Q#46786, answer score: 6