Difference between revisions of "Tarsnap"

From NixNet
m (decrease indentation level)
m (add category)
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
[[Category:Admin guides]]
 +
{{admin_guides}}
 +
Large portions of this guide were taken from Michael W Lucas' ''[https://shop.aer.io/mwl/p/Tarsnap_Mastery_Online_Backups_for_the_Truly_Paran/9780692400203-8826?collection=Technology_Books-177660 Tarsnap Mastery]''. I highly recommend it and anything else he's written.
 +
 
= Installation =
 
= Installation =
Package is called <code>tarsnap</code> on most distributions and is usually included in the official repos. After installation, generate a key and associate it with your Tarnsap account using the following command.
+
The package is called <code>tarsnap</code> on most distributions and is usually included in the official repos. If it's not, take a look at their [https://www.tarsnap.com/download.html download page]. After installation, generate a key and associate it with your Tarnsap account using the following command.
  
 
<pre>
 
<pre>
tarsnap-keygen --keyfile /root/tarsnap.key --user name@example.com --machine hostname
+
tarsnap-keygen --keyfile /root/tarsnap.key --user name@example.com --machine HOSTNAME
 
</pre>
 
</pre>
  
 
= Configuration =
 
= Configuration =
  
The configuration file is usually stored in <code>/etc/tarsnap/tarsnap.conf</code>. You may need to copy the sample configuration to the production config before editing.
+
The configuration file is usually stored in <code>/etc/tarsnap.conf</code>. You may need to copy the sample configuration to <code>/etc/</code> from elsewhere but it's likely already in the right place. This is what we use but make sure to look at the sample and read the manual before copying and pasting this.
  
 
<pre>
 
<pre>
Line 22: Line 26:
 
We use [https://github.com/alexjurkiewicz/acts/ ACTS] for automation. It stands for ''Another Calendar-based Tarsnap Script'' and manages backup creation and rotation. It keeps 31 daily backups, 12 monthly backups, and never deletes yearly backups; maintaining those are on you. When you feel like a specific yearly backup is no longer necessary, delete it yourself.
 
We use [https://github.com/alexjurkiewicz/acts/ ACTS] for automation. It stands for ''Another Calendar-based Tarsnap Script'' and manages backup creation and rotation. It keeps 31 daily backups, 12 monthly backups, and never deletes yearly backups; maintaining those are on you. When you feel like a specific yearly backup is no longer necessary, delete it yourself.
  
After adding a new user to our database that has read-only access to everything, we'll configure ACTS, create pre- and post-backup scripts for database dumps, then set up email alerts.
+
After adding a new user to our database that has read-only access to everything, we'll create pre- and post-backup scripts for managing database dumps, configure ACTS, then set up email alerts.
  
 
== Database dumps ==
 
== Database dumps ==
Refer to [[SQL Snippets]] for working with databases. Add a new user with a complicated password and lock/read-only permissions to all databases with the following SQL command.
+
Refer to [[SQL Snippets]] for more quick commands regarding SQL databases.  
 +
 
 +
=== Setting MySQL up ===
 +
Add a new user with a complicated password and minimal permissions to all databases with the following SQL command.
 
<pre>
 
<pre>
 
grant lock tables,show view,select on *.* to 'archive'@'localhost' identified by 'CHANGEMETOSOMETHINGSECURE';
 
grant lock tables,show view,select on *.* to 'archive'@'localhost' identified by 'CHANGEMETOSOMETHINGSECURE';
 
</pre>
 
</pre>
  
We store this script in <code>/usr/local/scripts/pre-acts.sh</code>. It simply dumps all databases to a backup SQL file for tarsnap to ingest.
+
=== Setting PostgreSQL up ===
 +
Same as above but PostgreSQL variant; you'll have to repeat these statements after connecting to ''every'' database you want backed up. From what I can tell, there is no way to give a user read-only permission across ''all'' PostgreSQL databases.
 +
<pre>
 +
CREATE ROLE archive WITH LOGIN ENCRYPTED PASSWORD 'CHANGEMETOSOMETHINGSECURE';
 +
\c dbname
 +
GRANT USAGE ON SCHEMA public TO archive;
 +
GRANT SELECT ON ALL TABLES IN SCHEMA public TO archive;
 +
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO archive;
 +
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO archive;
 +
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON SEQUENCES TO archive;
 +
</pre>
 +
 
 +
=== Scripting the dumps ===
 +
 
 +
We store scripts in <code>/usr/local/scripts</code> but you can put them wherever. This one is named <code>/usr/local/scripts/pre-acts.sh</code>. '''''Make sure to change the variables according to your needs.'''''
 
<pre>
 
<pre>
 
#!/bin/sh
 
#!/bin/sh
 +
 +
######################################################
 +
# MAKE SURE TO CHANGE VALUES ACCORDING TO YOUR NEEDS #
 +
######################################################
 +
 +
# Create a timestamp for dump names
 
DAY=$(date +%Y-%m-%d)
 
DAY=$(date +%Y-%m-%d)
DUMPFILE=/root/db_dumps/mysql-backup-$DAY.sql
+
 
touch $DUMPFILE
+
# Pick a database server, postgres or mysql
chown 0:0 $DUMPFILE
+
DATABASE=postgres
chmod 600 $DUMPFILE
+
 
mysqldump -u archive -pCHANGEMETOSOMETHINGSECURE --all-databases > $DUMPFILE
+
# Dump file location
 +
DUMPFILE=/root/db_dumps/$DATABASE-backup-$DAY
 +
 
 +
##########################
 +
# MYSQL-SPECIFIC OPTIONS #
 +
##########################
 +
MYSQLPASSWORD='CHANGEMETOSOMETHINGSECURE'
 +
 
 +
#############################
 +
# POSTGRES-SPECIFIC OPTIONS #
 +
#############################
 +
# Set the read-only user's password
 +
export PGPASSWORD='CHANGEMETOSOMETHINGSECURETOO'
 +
# Space-separated list of databases for backing up
 +
DBNAME="dbname1 dbname2"
 +
 
 +
case $DATABASE in
 +
    mysql)
 +
        touch $DUMPFILE
 +
        chown 0:0 $DUMPFILE
 +
        chmod 600 $DUMPFILE
 +
        mysqldump -u archive -p$MYSQLPASSWORD --all-databases > $DUMPFILE
 +
        ;;
 +
    postgres)
 +
        for i in $DBNAME
 +
        do
 +
            PGDUMP=$DUMPFILE-$i
 +
            touch $PGDUMP
 +
            chown 0:0 $PGDUMP
 +
            chmod 600 $PGDUMP
 +
            pg_dump -h 127.0.0.1 -U archive -Fp -n public -O -x -d $i > $PGDUMP
 +
        done
 +
        ;;
 +
esac
 +
exit
 
</pre>
 
</pre>
  
Line 46: Line 107:
 
find /root/db_dumps/ -type f -mtime +5 -delete
 
find /root/db_dumps/ -type f -mtime +5 -delete
 
</pre>
 
</pre>
 +
 +
Make sure these are marked as executable with <code>chmod +x /path/to/script.sh</code>.
  
 
== ACTS configuration ==
 
== ACTS configuration ==
It can be installed by simply <code>wget</code>ing <code>acts</code> and <code>acts.conf.sample</code>. Alternatively, clone the whole repository and symlink <code>acts</code> to wherever you like for easier updates then copy <code>acts.conf.sample</code> to <code>/etc/acts.conf</code>. We store scripts in <code>/usr/local/scripts</code> but you can put them wherever.
+
ACTS can be installed by simply <code>wget</code>ing <code>acts</code> and <code>acts.conf.sample</code> directly from [https://github.com/alexjurkiewicz/acts/ the repo]. Alternatively, you can clone the whole repository and symlink <code>acts</code> to wherever you like for easier updates then copy <code>acts.conf.sample</code> to <code>/etc/acts.conf</code>. The following is how we do it.
 +
 
 +
<pre>
 +
cd /root/
 +
git clone https://github.com/alexjurkiewicz/acts/
 +
ln -s /root/acts/acts /usr/local/scripts/acts
 +
</pre>
  
Make sure you reference the sample configuration file but these are the base options we use. Until you run ACTS and verify that your configuration works properly, leave <code>verbose</code> set to one. After you're sure everything works, set it to 0.
+
Make sure you reference the sample configuration file but these are the base options we use. Add additional directories to the <code>backuptargets</code> line, omitting the preceding <code>/</code>. Until you run ACTS and verify that your configuration works properly, leave <code>verbose</code> set to 1. After you're sure everything works, set it to 0. ACTS expects the config file to be located in <code>/etc/acts.conf</code>
  
 
<pre>
 
<pre>
Line 58: Line 127:
 
prebackupscript=/usr/local/scripts/pre-acts.sh
 
prebackupscript=/usr/local/scripts/pre-acts.sh
 
postbackupscript=/usr/local/scripts/post-acts.sh
 
postbackupscript=/usr/local/scripts/post-acts.sh
 +
</pre>
 +
 +
== Cronjob ==
 +
This runs ACTS at 02:30 on every day of every month.
 +
 +
<pre>
 +
# min  hour    day    month  weekday command
 +
30      2      *      *      *      /usr/local/scripts/acts
 
</pre>
 
</pre>
  
Line 64: Line 141:
  
 
= Backups =
 
= Backups =
Yes, backups for the backups are necessary. Specifically, backups of tarsnap ''keys'' are necessary. If you lose the key, you lose your backups. There is no way around this. While saving your key in a password manager, ina  text file on your PC, one someone else's PC, or even another server are all possible solutions, it's also good to have an offline copy Just In Case™. We use [https://github.com/intra2net/paperbackup paperbackup] because it's easily read by both machines (QR codes) and humans (plain text). Run your key through this, print the resulting PDF, put it in a folder, put the folder in a box, and put the box somewhere very very safe.
+
Yes, backups for the backups are necessary. Specifically, backups of backup ''keys'' are necessary; if you lose the key, you lose your backups. There is no way around this. While saving your key in a password manager, in a text file on your PC, on someone else's PC (please don't ever do this), or even on another server are all potential solutions, it's good to have an offline copy Just In Case™. We use [https://github.com/intra2net/paperbackup paperbackup] because it's easily read by both machines (QR codes) and humans (plain text); run your key through this, print the resulting PDF, put it in a folder, put the folder in a box, and put the box somewhere very very safe.

Revision as of 21:19, 16 September 2021

This article is part of a series of guides that describe NixNet's setup in excruciating detail. If you would like to follow them, please start at the Infrastructure page.

Large portions of this guide were taken from Michael W Lucas' Tarsnap Mastery. I highly recommend it and anything else he's written.

Installation

The package is called tarsnap on most distributions and is usually included in the official repos. If it's not, take a look at their download page. After installation, generate a key and associate it with your Tarnsap account using the following command.

tarsnap-keygen --keyfile /root/tarsnap.key --user name@example.com --machine HOSTNAME

Configuration

The configuration file is usually stored in /etc/tarsnap.conf. You may need to copy the sample configuration to /etc/ from elsewhere but it's likely already in the right place. This is what we use but make sure to look at the sample and read the manual before copying and pasting this.

cachedir /usr/local/tarsnap-cache
keyfile /root/tarsnap.key
nodump
print-stats
checkpoint-bytes 1G
humanize-numbers

Automation

We use ACTS for automation. It stands for Another Calendar-based Tarsnap Script and manages backup creation and rotation. It keeps 31 daily backups, 12 monthly backups, and never deletes yearly backups; maintaining those are on you. When you feel like a specific yearly backup is no longer necessary, delete it yourself.

After adding a new user to our database that has read-only access to everything, we'll create pre- and post-backup scripts for managing database dumps, configure ACTS, then set up email alerts.

Database dumps

Refer to SQL Snippets for more quick commands regarding SQL databases.

Setting MySQL up

Add a new user with a complicated password and minimal permissions to all databases with the following SQL command.

grant lock tables,show view,select on *.* to 'archive'@'localhost' identified by 'CHANGEMETOSOMETHINGSECURE';

Setting PostgreSQL up

Same as above but PostgreSQL variant; you'll have to repeat these statements after connecting to every database you want backed up. From what I can tell, there is no way to give a user read-only permission across all PostgreSQL databases.

CREATE ROLE archive WITH LOGIN ENCRYPTED PASSWORD 'CHANGEMETOSOMETHINGSECURE';
\c dbname
GRANT USAGE ON SCHEMA public TO archive;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO archive;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO archive;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO archive;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON SEQUENCES TO archive;

Scripting the dumps

We store scripts in /usr/local/scripts but you can put them wherever. This one is named /usr/local/scripts/pre-acts.sh. Make sure to change the variables according to your needs.

#!/bin/sh

######################################################
# MAKE SURE TO CHANGE VALUES ACCORDING TO YOUR NEEDS #
######################################################

# Create a timestamp for dump names
DAY=$(date +%Y-%m-%d)

# Pick a database server, postgres or mysql
DATABASE=postgres

# Dump file location
DUMPFILE=/root/db_dumps/$DATABASE-backup-$DAY

##########################
# MYSQL-SPECIFIC OPTIONS #
##########################
MYSQLPASSWORD='CHANGEMETOSOMETHINGSECURE'

#############################
# POSTGRES-SPECIFIC OPTIONS #
#############################
# Set the read-only user's password
export PGPASSWORD='CHANGEMETOSOMETHINGSECURETOO'
# Space-separated list of databases for backing up
DBNAME="dbname1 dbname2"

case $DATABASE in
    mysql)
        touch $DUMPFILE
        chown 0:0 $DUMPFILE
        chmod 600 $DUMPFILE
        mysqldump -u archive -p$MYSQLPASSWORD --all-databases > $DUMPFILE
        ;;
    postgres)
        for i in $DBNAME
        do
            PGDUMP=$DUMPFILE-$i
            touch $PGDUMP
            chown 0:0 $PGDUMP
            chmod 600 $PGDUMP
            pg_dump -h 127.0.0.1 -U archive -Fp -n public -O -x -d $i > $PGDUMP
        done
        ;;
esac
exit

This one is stored in /usr/local/scripts/post-acts.sh. It deletes all dumps older than 5 days.

#!/bin/sh
find /root/db_dumps/ -type f -mtime +5 -delete

Make sure these are marked as executable with chmod +x /path/to/script.sh.

ACTS configuration

ACTS can be installed by simply wgeting acts and acts.conf.sample directly from the repo. Alternatively, you can clone the whole repository and symlink acts to wherever you like for easier updates then copy acts.conf.sample to /etc/acts.conf. The following is how we do it.

cd /root/
git clone https://github.com/alexjurkiewicz/acts/
ln -s /root/acts/acts /usr/local/scripts/acts

Make sure you reference the sample configuration file but these are the base options we use. Add additional directories to the backuptargets line, omitting the preceding /. Until you run ACTS and verify that your configuration works properly, leave verbose set to 1. After you're sure everything works, set it to 0. ACTS expects the config file to be located in /etc/acts.conf

backuptargets="usr/local/scripts root/db_dumps"
tarsnapbackupoptions="--one-file-system --humanize-numbers"
verbose=1
prebackupscript=/usr/local/scripts/pre-acts.sh
postbackupscript=/usr/local/scripts/post-acts.sh

Cronjob

This runs ACTS at 02:30 on every day of every month.

# min   hour    day     month   weekday command
30      2       *       *       *       /usr/local/scripts/acts

Failure emails

TODO

Backups

Yes, backups for the backups are necessary. Specifically, backups of backup keys are necessary; if you lose the key, you lose your backups. There is no way around this. While saving your key in a password manager, in a text file on your PC, on someone else's PC (please don't ever do this), or even on another server are all potential solutions, it's good to have an offline copy Just In Case™. We use paperbackup because it's easily read by both machines (QR codes) and humans (plain text); run your key through this, print the resulting PDF, put it in a folder, put the folder in a box, and put the box somewhere very very safe.