Droplet Server Image
First step is to backup the system to make sure that I can restore if something goes sideways. Running
poweroff in the console will bring down the system, then using the Digital Ocean console to actually power down the system, create a named drive snapshot, then power up the system gets us a failsafe.
apt upgrade -y
apt autoremove -y
After a reboot all is up and well.
WordPress Site Backups
I found several helpful references on doing Easy Engine wordpress backups and settled on this (modified) script to produce some easy tarball backups of the sites and their dabases before doing an update.
mkdir -p $backup/$year/$month/$day
for i in $sites
echo "Starting backup for $i"
ee shell $i --command="wp db export ../$i.sql"
cd $ee/$i/app && tar --create --gzip --file $i.tar.xz htdocs $i.sql
mv $ee/$i/app/$i.tar.xz $backup/$year/$month/$day
These backup files can be inspected with
tar --list --gzip --file <file> and extracted with
tar --extract --gzip --file <file>
Update Easy Engine
ee cli update
WordPress Application Updates
With backups in place it should be safe to run the automatic updates in the WP sites. I tried running the updates from the wordpress.com/jetpack interface. I verified the updates in the wp admin pages. The jetpack integration seemed to work, but required some page reloads before all the updates would apply. My plugins are set to autoupdate, so no manual intervention was required.
A quick view of the sites didn’t show any problems. Disk usage on the droplet is at 50%. The bulk of usage is
/var/lib/docker/overlay2. I’ll need to keep an eye on that, since high overlay usage is a sign that changed files are being written in the containers, but not in volumes. It looks like cache plugins are writing temp files in there, which isn’t a big deal, since they shouldn’t grow, but if temp files or log files are getting written, it could be a problem.
Reminder to cleanup old backups in later update runs.