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

Re: backup directory/file exclusion pattern list for borgbackup



On Sat, Sep 25 2021 at 06:24:12 PM, Default User <hunguponcontent@gmail.com> wrote:
> Hello!
>
> I want to try using borgbackup to do backups of my (only) user directory:
> /home/debian-user
>
> I just want to do so using Vorta, a GUI for borgbackup.
>
> But I just need a good, general list of directory and file type
> exclusions that I can just cut and paste into the Exclude Patterns
> window in Vorta.  Something like the default list of exclusions that
> appears by default in the Backintime backup program.
>

I don't understand what a general list of exclusions would look like.
Do you have examples of what backintime excludes by default?  My own
borgbackup runs backup everything on disk; I don't feel the need to
exclude anything.

> Note 1: borgbackup uses a matching pattern called "Fnmatch" with which
> I am not familiar, and don't want to learn by trial and error, losing
> data in the process.  Which is why I am looking for a "drop-in" basic
> exclude list.
>

Run "borg help patterns" to see explanation of how borgbackup deals with
patterns.  It has this to say about fnmatch:

    This is the default style for --exclude and --exclude-from.  These
    patterns use a variant of shell pattern syntax, with '*' matching
    any number of characters, '?' matching any single character, '[...]'
    matching any single character specified, including ranges, and
    '[!...]'  matching any character not specified. For the purpose of
    these patterns, the path separator (backslash for Windows and '/' on
    other systems) is not treated specially. Wrap meta-characters in
    brackets for a literal match (i.e. [?] to match the literal
    character ?). For a path to match a pattern, the full path must
    match, or it must match from the start of the full path to just
    before a path separator. Except for the root path, paths will never
    end in the path separator when matching is attempted.  Thus, if a
    given pattern ends in a path separator, a '*' is appended before
    matching is attempted.

> Note 2: I am not intending to use borgbackup to back up the whole
> system; just /home/debian-user and its subdirectories.  I am using
> timeshift to back up the rest of the system.  Timeshift uses a huge
> amount of disk space, but it . . .  works.
>

I don't know how timeshift stores backups.  borg uses deduplicated
storage that avoids storing identical data multiple times.  My own borg
backups results in ~1G of new data every week (and about the same amount
being deleted from expiring backups).  There is no significant increase
in repository size week-over-week.  That obviously would not be the same
for everyone, but if you're bothered by the amount of disk space used
you can try it out.

> Note 3: I am aware that some use backintime to back up user data, and
> I have tried it myself.  But it just seems to have some "problems".
> For example, the built-in "diff" utility does not seem to do anything.
> It seems old and gives the impression of not being heavily developed.
> The documentation is "adequate" but mediocre. And what really grinds
> my gears about backintime, a problem apparently known as far back as
> 2014:
>
> "Warning: A recent security audit revealed several possible attack
> vectors for EncFs.
>
>>From https://defuse.ca/audits/encfs.htm:
>
> EncFS is probably safe as long as the adversary only gets one copy of
> the ciphertext and nothing more. EncFS is not safe if the adversary
> has the opportunity to see two or more snapshots of the ciphertext at
> different times. EncFS attempts to protect files from malicious
> modification, but there are serious problems with this feature.
>
> This might be a problem with Back In Time snapshots."
>
> Gee . . .  think so?

That report talks about issues with encfs design.  There is nothing
backintime can do to fix those.

borg can encrypt its backup images, and it recommendeds enabling that.
So an adversary would not get access to the encfs ciphertext directly.
They could get access to borg ciphertext instead, which may or may not
be vulnerable to the same problems.  AFAIK there hasn't been a security
audit of borgbackup itself.  The page at
https://borgbackup.readthedocs.io/en/stable/internals/security.html#borgcrypto
describes the design of borg security.

-- 
regards,
kushal


Reply to: