I just had a look at one of the log files from last night and I'm seeing the following at the top of the log file:
# cat /data/log/duply/home_a_incr_2017-04-10.log
Start duply v2.0.1, time is 2017-04-10 01:00:01.
INFO:
duplicity version check failed (please report, this is a bug)
Using profile '/etc/duply/home_a'.
Using installed duplicity version MISSING, python 2.7.13, gpg 2.0.14 (Home: ~/.gnupg), awk 'GNU Awk 3.1.7', grep 'grep (GNU grep) 2.20', bash '4.1.2(2)-release (x86_64-redhat-linux-gnu)'.
Autoset found secret key of first GPG_KEY entry '78ABCDEF' for signing.
Checking TEMP_DIR '/bup/duplicity' is a folder and writable (OK)
Test - Encrypt to '78ABCDEF' & Sign with '78ABCDEF' (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/bup/duplicity/duply.30881.1491811201_*'(OK)
Perhaps there is something wrong with the environment variables for duply jobs run in a cron setting? The backup jobs are completing successfully. The main problem at the moment is that the cache files aren't going where they are supposed to.
Cheers,
Scott
On Apr 9, 2017, at 11:09 AM, edgar.soldin--- via Duplicity-talk <address@hidden> wrote:
On 09.04.2017 19:52, Scott Classen via Duplicity-talk wrote:
Hello,
I have a dozen or so duply profiles. All of them have the cache directory specified as a separate volume on my main backup machine.
e.g.
# default '~/.cache/duplicity/duply_<profile>/'
# if set '${ARCH_DIR}/<profile>'
#ARCH_DIR=/some/space/safe/.duply-cache
ARCH_DIR=/bup/duplicity/.duply-cache
However, it appears that duply/duplicity is not honoring this configuration directive and all of the cache files are are going into /root/.cache/duplicity/
This is causing me severe headaches as the root partition is getting critically full.
hi Scott,
1.
what's your duply version?
2.0.1
2.
please run one backup w/ the '--preview' parameter and post it's result. check for and obfuscate private strings beforehand.
[root]# duply project status --previewStart duply v2.0.1, time is 2017-04-09 18:04:36.Using profile '/etc/duply/project'.Using installed duplicity version 0.7.12, python 2.7.13, gpg 2.0.14 (Home: ~/.gnupg), awk 'GNU Awk 3.1.7', grep 'grep (GNU grep) 2.20', bash '4.1.2(2)-release (x86_64-redhat-linux-gnu)'.Autoset found secret key of first GPG_KEY entry '78BD589D' for signing.-- Run cmd -- Checking TEMP_DIR ‘/bup/duplicity' is a folder and writable --test -d ‘/bup/duplicity' && test -w ‘/bup/duplicity' 2>&1-- Run cmd -- Test - Encrypt to '78BD589D' & Sign with '78BD589D' --echo password123 | gpg --sign --default-key 78BD589D --passphrase-fd 0 --batch -r 78BD589D --status-fd 1 -o ‘/bup/duplicity/duply.16873.1491786277_ENC' -e '/usr/bin/duply' 2>&1-- Run cmd -- Test - Decrypt --echo password123 | gpg --passphrase-fd 0 --batch -o ‘/bup/duplicity/duply.16873.1491786277_DEC' -d ‘/bup/duplicity/duply.16873.1491786277_ENC' 2>&1-- Run cmd -- Test - Compare --test "$(cat '/usr/bin/duply')" = "$(cat ‘/bup/duplicity/duply.16873.1491786277_DEC')" 2>&1Cleanup - Delete ‘/bup/duplicity/duply.16873.1491786277_*'(FAILED)--- Start running command STATUS at 18:04:37.283 ---TMPDIR=‘/bup/duplicity' PASSPHRASE=password123 FTP_PASSWORD=‘PASSWORD' '/usr/local/bin/python' '/usr/local/bin/duplicity' collection-status --archive-dir ‘/bup/duplicity/.duply-cache' --name duply_project --encrypt-key 78BD589D --sign-key 78BD589D --verbosity '4' --s3-use-rrs --asynchronous-upload 's3://address@hidden/backup-project'--- Finished state OK at 18:04:37.380 - Runtime 00:00:00.097 ---