On Wed, Nov 14, 2018 at 10:50:44AM -0500, Lee wrote: > On 11/14/18, Reco <recovery...@enotuniq.net> 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. > > 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. Reco
