Re: how to backup to an encrypted usb drive?
- Date: Wed, 14 Nov 2018 21:26:37 +0300
- From: Reco <recoverym4n@xxxxxxxxxxxx>
- Subject: Re: how to backup to an encrypted usb drive?
On Wed, Nov 14, 2018 at 12:52:57PM -0500, Lee wrote:
> On 11/14/18, Reco <recoverym4n@xxxxxxxxxxxx> wrote:
> > On Wed, Nov 14, 2018 at 10:50:44AM -0500, Lee wrote:
> >> On 11/14/18, Reco <recoverym4n@xxxxxxxxxxxx> wrote:
> >> > Hi.
> >> >
> >> > On Wed, Nov 14, 2018 at 10:01:38AM -0500, Lee wrote:
> >> >> What are you using to backup your files to an encrypted usb drive?
> >> >
> >> > For the backup itself - dump(8) or xfsdump(8) (filesystem dependent).
> >> Which seems to require restore or xfsrestore?
> > Precisely.
> >> https://linux.die.net/man/8/xfsdump
> >> The media format used by xfsdump can only be understood by xfsrestore.
> >> I can't tell from a quick look at dump/restore if I can look at files
> >> on the backup media or not
> > No, you do not. You'll need restore/xfsrestore first.
> > The whole purpose of a good filesystem backup is to capture all
> > file/directory attributes (which include, but aren't limited to POSIX
> > permissions, POSIX ACLs, SELinux labels, capability labels, extended
> > attributes to name a few). That's where dump/xfsdump guarantee you to
> > capture anything that a filesystem supports.
> > If you're content with losing all this metadata in your backup - there
> > are rsync, cpio or tar. Or all those 'backup solutions' based on those.
> Do I need all that metadata? This is for me at home so it's pretty
> much a single user machine.
That's for you to decide. I'd say you definitely need it for the backups
of / and /var and can *probably* skip it for /home, but YMMV.
> >> > For the encryption of this hypothetical drive (I don't use USB drives
> >> > for these purposes) - luks only.
> >> Why don't you like USB drives for these purposes?
> > Because backing up something to NFS share is easier.
> but leaves you open to cryptolocker ransomware & various 'oh shit!'
> moments when I do something stupid. Offline & offsite is worth a
> certain amount of inconvenience to me.
a) You do not do backups as a regular user.
b) You do not keep a single backup.
Besides, avoiding all those cryptolockers is easy. You just need to
learn to distinguish a trusted software from the untrusted. A trusted
software comes to you with your OS (in this case - Debian main archive).
An untrusted software comes from elsewhere. Keep to a trusted software
and you'll be fine.
Avoiding human mistakes is impossible indeed, hence the backups. And
filesystem snapshots, but that's a different matter.
> > And, I'm strong believer of 'machine works, human thinks' principle.
> > Automating backups to NFS (and replicating them from there) is simple.
> > Automating backup to USB drive - that's something that cannot be done
> > without human intervention.
> >> In other words, what am I missing?
A good backup is run by cron. A bad backup is run manually.
Simple as that.
> > Encrypted backups have their purpose, of course. For storing backups
> > offsite (whenever it's physical or cloud) encryption is invaluable.
> > But, the encryption is only as secure as the management of the
> > encryption key, and the only relatively secure example of that I can
> > come up with is gpg. And utilizing gpg for unattended backups is painful
> > to say the least.
> Which is why I liked truecrypt. Is luks roughly equivalent for
> encrypting the whole drive?
No, it's better. More encryption algorithms, definitely more code audit
*and* virtually zero 'became superuser' vulnerabilities.