A backup you have to babysit is not a backup. The whole point is that it runs without you, at 2 am, while you sleep, which means it cannot stop to ask anyone for a password. Day 10 was about making that automation genuinely hands-off and then giving a server an address that does not move.
One Linux task, one AWS task. Write a Bash script that zips a directory and ships it to a backup server over SSH, then associate an Elastic IP with an EC2 instance so its public address survives a reboot. The tasks come from the KodeKloud Engineer platform.
The backup script: zip, ship, and never type a password
The script itself is short. Zip a directory, then copy the archive to a remote backup server with scp:
#!/bin/bash
# Zip the target directory
zip -r /backup/xfusioncorp_official.zip /var/www/html/official
# Copy the archive to the backup server
scp /backup/xfusioncorp_official.zip clint@stbkp01:/backup
The catch is the scp line. By default, it asks for the remote user's password, and a script cannot type one. So before this can run unattended, you set up key-based SSH between the two machines, exactly like Day 7:
# On the source server, once
ssh-keygen # generate a key pair if you don't have one
ssh-copy-id clint@stbkp01 # push the public key to the backup server
Now the source server logs into the backup server with its key, no prompt, and scp runs silently. Make the script executable and run it:
chmod +x /scripts/official_backup.sh
/scripts/official_backup.sh
Two practical notes. The /backup directory has to exist before zip writes to it, or the script fails on the first line. And this is the natural partner to Day 6's cron. Drop this script into a crontab line, and the backup runs itself every night. That is the moment a script stops being a command you run and becomes a system that runs on its own.
Elastic IP: a fixed address, and a new line on the bill
On the AWS side, the task was to give an instance a stable public IP. A normal EC2 public IP is temporary, it changes every time the instance stops and starts, which breaks anything pointing at it. An Elastic IP is a public IPv4 address you allocate and hold onto, and it stays put across reboots. Associating one is straightforward:
# Find the allocation ID of your Elastic IP
aws ec2 describe-addresses
# Associate it with the instance
aws ec2 associate-address \
--instance-id i-0b263919b6498b123 \
--allocation-id eipalloc-64d5890a
# Confirm the association
aws ec2 describe-addresses --allocation-ids eipalloc-64d5890a
Here is where I have to correct some old advice, including what my own notes said. It used to be true that an Elastic IP was free as long as it was attached to a running instance, and you only paid for idle ones. That is no longer the case. Since February 1, 2024, AWS charges for every public IPv4 address, about $0.005 an hour, whether it is attached or not, which works out to roughly $3.60 a month per address (per the AWS pricing announcement). There is a free tier of 750 hours a month for the first year, but the old attached-equals-free model is gone. The practical advice is what it always was: do not hoard public IPv4, except now it costs you even while in use.
One more detail. The default quota is 5 Elastic IPs per region. It is adjustable, but it exists to discourage exactly that hoarding.
What Day 10 was really about
Both tasks were about doing permanence properly. The backup script only works if the trust between the two servers is set up once and then stays out of the way. The Elastic IP only helps if you treat it as a resource you own and pay for, not a free convenience. Automation and cloud both pay you back for setting things up deliberately and knowing what they cost.
So here is the Day 10 question. Would you rather wire up automation that runs itself and know exactly what each piece costs, or keep doing the work by hand because the setup felt like too much effort up front?
Day 10 down. Ninety to go.
Top comments (0)