Re: how to backup to an encrypted usb drive?
On Wed, Nov 14, 2018 at 10:50:44AM -0500, Lee wrote:
> On 11/14/18, Reco <email@example.com> 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?
> 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.
> > 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.
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?
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.