Tag: backup

Setting up an automated mySQL / MariaDB backup schedule

Just digging deeper in automating thing, so I made two scripts:

backup_cron.sh
#!/bin/bash

# Define the path to the backup script
BACKUP_SCRIPT="/backup_mysql.sh"

# Define the cron job command to run the backup script once a week (every Sunday at midnight)
CRON_COMMAND="0 0 * * 0 $BACKUP_SCRIPT"

# Add the cron job to the crontab
(crontab -l 2>/dev/null; echo "$CRON_COMMAND") | crontab -

echo "Backup cron job set up successfully."

And the script that executes the backup every Sunday:

backup_mysql.sh
#!/bin/bash

# Define the directory where backup files will be stored
BACKUP_DIR="/var/backups/mysql"

# Ensure the backup directory exists
mkdir -p "$BACKUP_DIR"

# Define the filename for the backup file (include date in the filename)
BACKUP_FILE="$BACKUP_DIR/mysql_backup_$(date +%Y-%m-%d_%H-%M-%S).sql"

# Define the compressed filename
COMPRESSED_FILE="$BACKUP_FILE.gz"

# Define MySQL username and password (replace with your MySQL credentials)
DB_USER="USERNAME"
DB_PASS="PASSWORD"

# Dump all databases into a single SQL file
mysqldump -u "$DB_USER" -p"$DB_PASS" --all-databases > "$BACKUP_FILE"

# Add permissions to the backup file
chmod 600 "$BACKUP_FILE"

# Compress the backup file
gzip "$BACKUP_FILE"

echo "Database backup completed. Backup stored in: $COMPRESSED_FILE"

To make the script executable:

sudo chmod +x backup_cron.sh
sudo chmod +x backup_mysql.sh

and run it with

sudo ./backup_cron.sh

Loading

How to update Mastodon to a new version

EXPIRED: NEW GUIDE AVAILABLE HERE

Updating Mastodon and creating backups are important steps to ensure the security and stability of your instance. Here’s a comprehensive tutorial on how to update Mastodon, including making backups of the database and assets:

Note 1: Always perform updates on a test/staging instance before applying them to your live instance. This tutorial assumes you have some basic command line and server administration knowledge.

Note 2: If you made alterations to your files and want to update to a new branch, like v4.2.0, don’t forget to stash your files first. DO THIS AT YOUR OWN RISK.

cd /home/mastodon/live
git stash

You will not have an error message any more when entering:
I currently do not know how to put the stashed files back, this will be found out later.

git checkout v4.2.0

Note 3: If you switch to a new branch and version, like 4.2.0, you might run into an error stating the following:

rbenv: version '3.2.2' is not installed (set by /home/mastodon/live/.ruby-version)

Take the following steps to solve this problem:
(Type the version you need where it says x.x.x)

rbenv install x.x.x

If that fails, try the following command:

brew update && brew upgrade ruby-build

Followed by:
(Type the version you need where it says x.x.x)

rbenv install x.x.x

OPTIONAL: If bundler or rails fails to work, try the following commands:

gem install bundler

gem install rails

Click here for the backup steps. It basically comes down to a Database dump, a settings file backup and a Redis dump. If you wish to backup your assets like images and stuff (User-uploaded files), backup the folder named “public/system”. Keep in mind that this folder can be rather large. Actually, it can become rather massive.

After a good 90 minutes, I gave up on trying to show you how large the asset folder is. So beware if you are going to make a backup of it. Perhaps you can just skip the cache folder?

You can always check the folder size by using NCDU, for which you can find the manual here. Also, installations may vary, but this is an example of my instance.

Upgrade procedure.

  1. su - mastodon
  2. cd /home/mastodon/live
  3. git fetch --tags
  4. git checkout [type the most recent version here, starting with the letter v. For example; v4.0.1

Command example: git checkout v4.0.1
  5. bundle install
  6. yarn install
  7. RAILS_ENV=production bundle exec rails db:migrate
  8. RAILS_ENV=production bundle exec rails assets:precompile
  9. exit
  10. reboot now

And that should be it!

If you don’t want to restart your server, use the following commands instead of “reboot now”:

  1. exit
  2. systemctl restart mastodon-sidekiq
  3. systemctl reload mastodon-web

    The reload operation is a zero-downtime restart, also called a “phased restart”. As such, Mastodon upgrades usually do not require any advance notice to users about planned downtime. In rare cases, you can use the restart operation instead, but there will be a (short) felt interruption of service for your users.

  4. The streaming API server is also updated and requires a restart; doing so will result in all connected clients being disconnected, which can increase the load on your server:
systemctl restart mastodon-streaming

Done!

PS: When I updated my instance from 4.1.9 to 4.2.0, a lot of warnings flew by, and this is, in my experience, not a problem as the instance is working perfectly.

Loading