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

Re: Tarsnap failing to make backups

On 2020-04-14 17:49, Graham Percival wrote:
On Tue, Apr 14, 2020 at 04:27:18PM -0400, Michael Jung wrote:
Tarsnap runs as "root" via cron although it still fails if I run in

Do you mean that Tarsnap "attempts to run as root via cron (but fails)", or
"it successfully runs as root via cron"?

Occasionally somebody will get confused between running tarsnap as root vs. with a regular account. If your user has a ~/.tarsnaprc which points to an
old cache directory (which you might have used while initially
testing/configuring tarsnap), that would explain the discrepancy.

Or conversely, your user account might have a working ~/.tarsnaprc which overrides settings from /usr/local/etc/tarsnap.conf; in that case, I would expect commands run by your user to work but commands run by root to fail.

Is there any debugging that can be turned on to get a better idea of whats
going on?

Not off the top of my head in 1.0.39. --noisy-warnings will complain about network issues, and -v will produce verbose output about each file that it's writing. I don't think that either flag will help with fsck-related issues,

There's a --dump-config flag in the unreleased git master (which will become 1.0.40 in the future), which would help to debug the "is tarsnap reading from
a config file I didn't realize?" problem.

If this email about "user account vs. root account" doesn't spark a solution, I can create a new git branch which adds extra debug ouput related to fsck.

- Graham

I apologize for not being more clear. As to my comment about cron, I was simply trying to state that both the cron job running as "root", or myself
running tarsnap as the user "root" manually both fail in the same way.

I have confirmed that the home directory for "root" does not have a .tarsnap file.

Here is my tarsnap.conf from /usr/local/etc/tarsnap.conf

Nothing sticks out to me as interesting but I'm not the expert here :-)

[root@firewall ~]# cat /usr/local/etc/tarsnap.conf
### Recommended options

# Tarsnap cache directory
cachedir /usr/local/tarsnap-cache

# Tarsnap key file
keyfile /root/tarsnap.key

# Don't archive files which have the nodump flag set.

# Print statistics when creating or deleting archives.

# Create a checkpoint once per GB of uploaded data.
checkpoint-bytes 1G

### Commonly useful options

# Use SI prefixes to make numbers printed by --print-stats more readable.

### Other options, not applicable to most systems

# Aggressive network behaviour: Use multiple TCP connections when
# writing archives.  Use of this option is recommended only in
# cases where TCP congestion control is known to be the limiting
# factor in upload performance.

# Exclude files and directories matching specified patterns.
# Only one file or directory per command; multiple "exclude"
# commands may be given.

# Include only files and directories matching specified patterns.
# Only one file or directory per command; multiple "include"
# commands may be given.

# Attempt to reduce tarsnap memory consumption.  This option
# will slow down the process of creating archives, but may help
# on systems where the average size of files being backed up is
# less than 1 MB.

# Try even harder to reduce tarsnap memory consumption.  This can
# significantly slow down tarsnap, but reduces its memory usage
# by an additional factor of 2 beyond what the lowmem option does.

# Snapshot time.  Use this option if you are backing up files
# from a filesystem snapshot rather than from a "live" filesystem.
#snaptime <file>
[root@firewall ~]#

If you think of anything I might do on my end let me know.  I hope
that this is not some weird problem on my installation but you
never know.

As to a github repository to test from I'm comfortable in checking
that out and compiling from source.

I will tell you more about my environment but understand it has not
changed in years other than the occasional upgrade to the FreeBSD
source tree, compiling new kernels and userland and upgrading various
ports via poudriere.

FreeBSD here runs under ESXi 5.5.  Both the tarsnap cache directory
and the binaries are on a UFS2 partition.  Everthing else on the system
is working without issue. e.g. Apache24, plex, php, various web applications
and system tools.  All other filesystems on this system utilize ZFS.

I don't have any evidence of any other issues from either application logs
or from /var/log/messages nor dmesg.

If it helps, my registered email account on tarsnap is "mikej@mikej.com".

Thank you for you time and interest in helping me resolve my issue.

Michael Jung