[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Nope. Because:

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.


Reply to: