[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
manually.
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,
though.
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.
Cheers,
- 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.
nodump
# Print statistics when creating or deleting archives.
print-stats
# 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.
#humanize-numbers
### 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.
#aggressive-networking
# Exclude files and directories matching specified patterns.
# Only one file or directory per command; multiple "exclude"
# commands may be given.
#exclude
# Include only files and directories matching specified patterns.
# Only one file or directory per command; multiple "include"
# commands may be given.
#include
# 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.
#lowmem
# 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.
#verylowmem
# 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.
--mikej
Michael Jung