a first cut
This commit is contained in:
parent
5e556e0449
commit
20ddee6aea
1 changed files with 136 additions and 0 deletions
136
README.md
136
README.md
|
|
@ -0,0 +1,136 @@
|
||||||
|
# Backup using Dump and GPG Encryption
|
||||||
|
|
||||||
|
So you want to back up to a remote system, and you want it encrypted before it leaves the source system. This hack uses classic UNIX `dump`; sorry for the brutality. This example is also not incremental; your refund is in the post. Let's assume the source system is Debian Linux.
|
||||||
|
|
||||||
|
## Source Syatem backup User
|
||||||
|
|
||||||
|
By default, both UNIX and Linux have a `backup` user, but with a strange directory etc. So, on the source system, we will hack to instantiate the desired user.
|
||||||
|
|
||||||
|
```
|
||||||
|
sudo mkdir /home/backup
|
||||||
|
sudo chown backup:backup /home/backup
|
||||||
|
```
|
||||||
|
|
||||||
|
Use `vipw` to configure `/home/backup` as the backup user's home directory. It should look something similar to
|
||||||
|
|
||||||
|
```
|
||||||
|
backup:x:34:34:backup:/home/backup:/bin/bash
|
||||||
|
```
|
||||||
|
|
||||||
|
You may also want to configure the user so you are comfortable, i.e. add `.emacs` `.bashrc`, etc.
|
||||||
|
|
||||||
|
You probably want your laptop's ssh public key to let you into the backup user account, so
|
||||||
|
|
||||||
|
```
|
||||||
|
sudo mkdir /home/backup/.ssh
|
||||||
|
sudo chmod 700 /home/backup/.ssh
|
||||||
|
sudo touch /home/backup/.ssh/authorised_keys
|
||||||
|
sudo 600 chmod /home/backup/.ssh/authorised_keys
|
||||||
|
sudo chown -Rbackup:backup /home/backup
|
||||||
|
```
|
||||||
|
|
||||||
|
and then somehow `cat` or copy your public key into `/home/backup/.ssh/authorised_keys`.
|
||||||
|
|
||||||
|
Test that you can `ssh backup@source.host`
|
||||||
|
|
||||||
|
You need to get the backup user so they can `sudo` without a passphrase.
|
||||||
|
|
||||||
|
## The SSH Key
|
||||||
|
|
||||||
|
For authenticating to the backup server and for transport encryption, you will want a separate ssh key for the purpose.
|
||||||
|
|
||||||
|
SSH into the source host as the backup user
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
ssh-keygen -t ed25519
|
||||||
|
```
|
||||||
|
|
||||||
|
Agree to save the key pair in `/home/backup/.ssh/id_ed25519.
|
||||||
|
|
||||||
|
Hit <enter> so no passphrase, and once again.
|
||||||
|
|
||||||
|
Now take /home/backup/.ssh/id_ed25519.pub and give it to the sysadmin of the destination backup server. They will install it in `/home/backup/.ssh/authorised_keys` on the backup server.
|
||||||
|
|
||||||
|
Test that the backup user on the source system can ssh to the backup server. You will have to accept that server's ssh host key.
|
||||||
|
|
||||||
|
## Install dump
|
||||||
|
|
||||||
|
If you will be using UNIX dump/restore, you need to install it.
|
||||||
|
|
||||||
|
```
|
||||||
|
sudo apt install dump
|
||||||
|
```
|
||||||
|
|
||||||
|
If you do not intend to back up entire filesystems, instead you could use tar or some equivalent. For the moment, assume dump.
|
||||||
|
|
||||||
|
## Generate the GPG Key Used for File Encryption
|
||||||
|
|
||||||
|
As with the SSH key, you will want a separate GOG key for the file encryption. It's simpler. Again, as the backup user on the source host
|
||||||
|
|
||||||
|
```
|
||||||
|
gpg --gen-key
|
||||||
|
```
|
||||||
|
|
||||||
|
The real name might be yours, or maybe "Backup User". Use your email address when asked. Say OK. To use a null passphrase, hit <enter> at the passphrase prompts.
|
||||||
|
|
||||||
|
If you are on a VM, entropy is scarce, so it will hang forever. There is a disgusting hack as follows:
|
||||||
|
|
||||||
|
```
|
||||||
|
sudo apt install haveged
|
||||||
|
```
|
||||||
|
|
||||||
|
and then have another go at GPG key generation.
|
||||||
|
|
||||||
|
You will want to capture the key identity for later use. So
|
||||||
|
|
||||||
|
```
|
||||||
|
gpg --list-keys
|
||||||
|
```
|
||||||
|
|
||||||
|
and there will be some long grotty key id such as `C6E74374512CD33FD1C2E47A7E84C28C1F64EAAF`.
|
||||||
|
|
||||||
|
## The Script
|
||||||
|
|
||||||
|
And now we wrap it all up in a grotty script
|
||||||
|
|
||||||
|
```
|
||||||
|
cat > do-dump << EOF
|
||||||
|
gogs.sjc.arrcus.com:/home/backup> cat do-dump
|
||||||
|
#!/bin/sh
|
||||||
|
|
||||||
|
BSYS="raid0.sea.rg.net"
|
||||||
|
USYS="backup@$BSYS"
|
||||||
|
BDIR="/backup/arrcus"
|
||||||
|
HOST=`hostname`
|
||||||
|
DATE=`date "+%Y-%m-%d"`
|
||||||
|
DDIR="$BDIR/$HOST.$DATE"
|
||||||
|
DEST="$USYS:$DDIR"
|
||||||
|
SSH="/usr/bin/ssh -i /home/backup/.ssh/id_ed25519"
|
||||||
|
KEY_ID=C6E74374512CD33FD1C2E47A7E84C28C1F64EAAF
|
||||||
|
GPG="/usr/bin/gpg --no-options --batch --no-greeting --no-secmem-warning --keyring /home/backup/.gnupg/pubring.kbx --secret-keyring /home/backup/.gnupg/secring.gpg --trustdb-name /home/backup/.gnupg/trustdb.gpg --digest-algo sha256 --cipher-algo aes256 --s2k-cipher-algo aes256 --s2k-digest-algo sha512 --encrypt --recipient $KEY_ID"
|
||||||
|
|
||||||
|
# gogs.sjc.arrcus.com
|
||||||
|
#
|
||||||
|
# Filesystem Size Used Avail Use% Mounted on
|
||||||
|
# /dev/vda1 61G 2.5G 56G 5% /
|
||||||
|
|
||||||
|
$SSH $USYS mkdir $DDIR
|
||||||
|
for F in base; do
|
||||||
|
$SSH $USYS touch $DDIR/$F
|
||||||
|
done
|
||||||
|
|
||||||
|
sudo /sbin/dump -0uab 64 -f - / | $GPG | $SSH $USYS "/bin/cat > $DDIR/base"
|
||||||
|
EOF
|
||||||
|
```
|
||||||
|
|
||||||
|
You probably will want to change
|
||||||
|
* `BSYS` to whatever you have agreed with the target system's admin
|
||||||
|
* `BDIR` wherever she told you you could stash your backups
|
||||||
|
* `KEY_ID` to the GPG key from above
|
||||||
|
|
||||||
|
And then modify the actual dumping details.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
2020.01.06
|
||||||
Loading…
Add table
Add a link
Reference in a new issue