cleaned up after a bit of review

This commit is contained in:
Randy Bush 2020-01-06 21:00:26 -08:00
parent 20ddee6aea
commit 3fcf10b12e

View file

@ -1,6 +1,6 @@
# Backup using Dump and GPG Encryption
# 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.
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. As noted below, you could use `tar` or something similar. 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
@ -19,14 +19,14 @@ 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
You probably want your laptop's ssh public key to let you into the backup user account, and you will need a `~/.ssh` directory anyway. 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
sudo chown -R backup:backup /home/backup
```
and then somehow `cat` or copy your public key into `/home/backup/.ssh/authorised_keys`.
@ -46,9 +46,9 @@ 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.
Agree to save the key pair in `/home/backup/.ssh/id_ed25519`.
Hit <enter> so no passphrase, and once again.
Hit return 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.
@ -56,23 +56,23 @@ Test that the backup user on the source system can ssh to the backup server. Yo
## 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.
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
As with the SSH key, you will want a separate GPG 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.
The real name might be yours, or maybe "Backup User". Use your email address when asked. Say OK. To use a null passphrase, hit return 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:
@ -122,6 +122,7 @@ for F in base; do
sudo /sbin/dump -0uab 64 -f - / | $GPG | $SSH $USYS "/bin/cat > $DDIR/base"
EOF
chmod 755 do-dump
```
You probably will want to change
@ -131,6 +132,15 @@ You probably will want to change
And then modify the actual dumping details.
## cron
You probably want to run it out of cron with some hack such as the following:
```
ran.psg.com:/home/randy> grep dump /etc/crontab
30 8 * * * root /home/backup/do-dump
```
---
2020.01.06