backupninja issueshttps://0xacab.org/liberate/backupninja/-/issues2020-12-31T16:12:39Zhttps://0xacab.org/liberate/backupninja/-/issues/11316Luks2 headers not recognized by sys handler, emits warning2020-12-31T16:12:39ZJerome CharaouiLuks2 headers not recognized by sys handler, emits warningSince the luksDump format is quite different between LUKS version 1 and 2, backupninja fails to recognize the newer format and emits a warning in the logs even though the output is valid.
```
Dec 27 15:50:37 Debug: /usr/sbin/cryptset...Since the luksDump format is quite different between LUKS version 1 and 2, backupninja fails to recognize the newer format and emits a warning in the logs even though the output is valid.
```
Dec 27 15:50:37 Debug: /usr/sbin/cryptsetup luksDump "/dev/ram1" | grep '^Payload offset:' | /usr/bin/awk '{print }'
Dec 27 15:50:37 Warning: The computed size of LUKS header is not an integer, skipping /dev/ram1
```
The luksDump output for LUKS version 2 looks like this:
```
$ sudo /usr/sbin/cryptsetup luksDump "/dev/ram1"
LUKS header information
Version: 2
Epoch: 3
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 50137cd5-508d-4b5f-bc59-5a9c2f548e86
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2i
Time cost: 17
Memory: 247388
Threads: 2
Salt: 67 25 66 a0 ec 06 9d 90 b7 15 96 dc 1d 86 22 4d
35 db 93 10 c7 f8 50 63 1e 11 f9 28 2b 26 d0 a1
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 130031
Salt: 4f 87 9b ef cb 47 75 fb 60 8a 6b cf f9 64 34 e4
f5 56 6f d1 27 4e 4f 19 90 0a 29 e6 43 df 27 4b
Digest: 27 be 0a 7c 9b 04 ba 31 16 42 f8 a8 f5 a6 85 e8
3b 27 9f 18 d2 f5 42 c5 fa 36 c3 b0 92 af 20 ba
```
For comparison, this is the version 1 output:
```
$ sudo /usr/sbin/cryptsetup luksDump "/dev/ram1"
LUKS header information for /dev/ram1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
MK digest: 32 6e ea c7 70 b0 42 d8 e8 ed 84 f4 c1 c5 7d 02 4b 50 61 43
MK salt: 19 69 0d 51 70 63 60 45 c0 30 ce 0d d6 af 1e e9
b2 5d 1d 6e 16 87 00 af 01 f5 50 8f 9e 45 1f bd
MK iterations: 128501
UUID: 6410c635-6ebe-44ae-b9d2-27207be763d8
Key Slot 0: ENABLED
Iterations: 2044006
Salt: 5f d7 5a be ab ba f7 c4 4b 56 ac f3 6f db e9 66
7b 10 96 02 04 92 a7 d7 0e 0c 3b 82 d9 55 64 09
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
```1.2.0-rc1https://0xacab.org/liberate/backupninja/-/issues/11311borg should report a warning if borg exits with exit code 12021-01-10T21:26:38ZJamie McClellandborg should report a warning if borg exits with exit code 1Right now, backupninja reports a fatal error if borg exits with 1 (or anything other then 0).
However [an exit code of 1](https://borgbackup.readthedocs.io/en/stable/usage/general.html) should be considered a warning, not an error.
Thi...Right now, backupninja reports a fatal error if borg exits with 1 (or anything other then 0).
However [an exit code of 1](https://borgbackup.readthedocs.io/en/stable/usage/general.html) should be considered a warning, not an error.
This is a useful change because now backupninja reports a fatal error if borg simply failed to backup a file that was removed during the backup.
Thanks!1.2.0-rc1Guillaume SubironGuillaume Subironhttps://0xacab.org/liberate/backupninja/-/issues/11304[borg handler] quotes missing in $create_options test2021-01-07T03:36:00ZJerome Charaoui[borg handler] quotes missing in $create_options testLine 127, needs quoting around `$create_options`, otherwise multiple space-separated options cause the handler to fail.Line 127, needs quoting around `$create_options`, otherwise multiple space-separated options cause the handler to fail.1.2.0-rc1Emil BreinerEmil Breinerhttps://0xacab.org/liberate/backupninja/-/issues/11303[sys handler] MBR backups include loopback devices mounted by snaps2021-01-25T17:40:40ZVarac[sys handler] MBR backups include loopback devices mounted by snapsI have some snaps installed on ubuntu and using `mbr = yes` results in too many unwanted mbr backups:
```
Debug: Will try to backup MBR tables for device /dev/loop0
Debug: /bin/dd if=/dev/loop0 of=/var/backups/mbr.loop0.bin bs=512 count...I have some snaps installed on ubuntu and using `mbr = yes` results in too many unwanted mbr backups:
```
Debug: Will try to backup MBR tables for device /dev/loop0
Debug: /bin/dd if=/dev/loop0 of=/var/backups/mbr.loop0.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop1
Debug: /bin/dd if=/dev/loop1 of=/var/backups/mbr.loop1.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop2
Debug: /bin/dd if=/dev/loop2 of=/var/backups/mbr.loop2.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop3
Debug: /bin/dd if=/dev/loop3 of=/var/backups/mbr.loop3.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop4
Debug: /bin/dd if=/dev/loop4 of=/var/backups/mbr.loop4.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop5
Debug: /bin/dd if=/dev/loop5 of=/var/backups/mbr.loop5.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop6
Debug: /bin/dd if=/dev/loop6 of=/var/backups/mbr.loop6.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop7
Debug: /bin/dd if=/dev/loop7 of=/var/backups/mbr.loop7.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/sda
Debug: /bin/dd if=/dev/sda of=/var/backups/mbr.sda.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/mapper/sda5_crypt
Debug: /bin/dd if=/dev/mapper/sda5_crypt of=/var/backups/mbr.mapper-sda5_crypt.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/mapper/ubuntu--vg-root
Debug: /bin/dd if=/dev/mapper/ubuntu--vg-root of=/var/backups/mbr.mapper-ubuntu--vg-root.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/mapper/ubuntu--vg-swap_1
Debug: /bin/dd if=/dev/mapper/ubuntu--vg-swap_1 of=/var/backups/mbr.mapper-ubuntu--vg-swap_1.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/mapper/ubuntu--vg-home
Debug: /bin/dd if=/dev/mapper/ubuntu--vg-home of=/var/backups/mbr.mapper-ubuntu--vg-home.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop8
Debug: /bin/dd if=/dev/loop8 of=/var/backups/mbr.loop8.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop9
Debug: /bin/dd if=/dev/loop9 of=/var/backups/mbr.loop9.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop10
Debug: /bin/dd if=/dev/loop10 of=/var/backups/mbr.loop10.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop11
Debug: /bin/dd if=/dev/loop11 of=/var/backups/mbr.loop11.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop12
Debug: /bin/dd if=/dev/loop12 of=/var/backups/mbr.loop12.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop13
Debug: /bin/dd if=/dev/loop13 of=/var/backups/mbr.loop13.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop14
Debug: /bin/dd if=/dev/loop14 of=/var/backups/mbr.loop14.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop15
Debug: /bin/dd if=/dev/loop15 of=/var/backups/mbr.loop15.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop16
Debug: /bin/dd if=/dev/loop16 of=/var/backups/mbr.loop16.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop17
Debug: /bin/dd if=/dev/loop17 of=/var/backups/mbr.loop17.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop18
Debug: /bin/dd if=/dev/loop18 of=/var/backups/mbr.loop18.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop19
Debug: /bin/dd if=/dev/loop19 of=/var/backups/mbr.loop19.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop20
Debug: /bin/dd if=/dev/loop20 of=/var/backups/mbr.loop20.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop21
Debug: /bin/dd if=/dev/loop21 of=/var/backups/mbr.loop21.bin bs=512 count=1 2>/dev/null
Debug: Will try to backup MBR tables for device /dev/loop22
Debug: /bin/dd if=/dev/loop22 of=/var/backups/mbr.loop22.bin bs=512 count=1 2>/dev/null
…
```
These loopback devices are created by snaps:
```
# mount | grep snap
/var/lib/snapd/snaps/shellcheck_797.snap on /snap/shellcheck/797 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/chromium_937.snap on /snap/chromium/937 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/atom_238.snap on /snap/atom/238 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/subliminal-subtitles_34.snap on /snap/subliminal-subtitles/34 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-28-1804_91.snap on /snap/gnome-3-28-1804/91 type squashfs (ro,nodev,relatime,x-gdu.hide)
…
```1.2.1https://0xacab.org/liberate/backupninja/-/issues/11294[redhat] error "/usr/local/share/backupninja/sys: ligne 265 : [: too many arg...2021-01-13T08:55:56ZNima[redhat] error "/usr/local/share/backupninja/sys: ligne 265 : [: too many arguments"Hello,
I ran into errors testing backupninja on RedHat (RHEL7):
> /usr/local/share/backupninja/sys: ligne 265 : [: too many arguments
> /usr/local/share/backupninja/sys: ligne 270 : [: too many arguments
This patch on `handlers/sys`...Hello,
I ran into errors testing backupninja on RedHat (RHEL7):
> /usr/local/share/backupninja/sys: ligne 265 : [: too many arguments
> /usr/local/share/backupninja/sys: ligne 270 : [: too many arguments
This patch on `handlers/sys` seems to solve this issue:
```
--- handlers/sys 2018-09-10 11:40:34.781597844 +0200
+++ /usr/local/share/backupninja/sys 2018-09-10 12:14:48.270597844 +0200
@@ -310,7 +310,7 @@
if [ $os = "redhat" ]; then
catifexec "/sbin/chkconfig" "--list"
STATUS="Collecting information about /etc/rc.d:"
- catiffile "/bin/ls /etc/rc.d/rc*.d/"
+ catiffile $(/bin/ls /etc/rc.d/rc*.d/)
elif [ $os = "debian" ]; then
for level in 0 1 2 3 4 5 6 S; do
```
Regards,1.2.0-rc1JulienJulienhttps://0xacab.org/liberate/backupninja/-/issues/11286dup handler silently fails if cache directory isn't created2018-08-02T00:49:40Znosmodup handler silently fails if cache directory isn't createdWhen creating a backup from scratch, if the parent of the archive_dir used by duplicity commands is not present, the duplicity job will silently fail and the user will be told the operation was a success:
```
nosmo@Hologram-Rose backup...When creating a backup from scratch, if the parent of the archive_dir used by duplicity commands is not present, the duplicity job will silently fail and the user will be told the operation was a success:
```
nosmo@Hologram-Rose backupninja =) $ sudo ./src/backupninja -t -d -n -f ./etc/backupninja.conf
Debug: check_perms etc/backup.d
Debug: perms: drwx--x---
Debug: gperm: --x
Debug: wperm: ---
Debug: check_perms etc/backup.d/example.dup
Debug: perms: -rwx------
Debug: gperm: ---
Debug: wperm: ---
Info: >>>> starting action etc/backup.d/example.dup (because of --now)
Debug: yes
Debug: executing handler in locked section controlled by /var/lock/backupninja/etc_backup.d_example.dup
Debug: Data will be encrypted with the GnuPG key KEY_ID.
Debug: Data will be signed will the GnuPG key KEY_ID.
Debug: LC_ALL=C duplicity cleanup --force --s3-european-buckets --s3-use-new-style --no-print-statistics --ssh-options '' --encrypt-key KEY_ID --sign-key KEY_ID --full-if-older-than 30D --archive-dir /var/cache/backupninja/duplicity s3+http://my-backup/
Debug: LC_ALL=C duplicity remove-older-than 60D --force --s3-european-buckets --s3-use-new-style --no-print-statistics --ssh-options '' --encrypt-key KEY_ID --sign-key KEY_ID --full-if-older-than 30D --archive-dir /var/cache/backupninja/duplicity s3+http://my-backup/
Debug: LC_ALL=C duplicity --s3-european-buckets --s3-use-new-style --no-print-statistics --ssh-options '' --encrypt-key KEY_ID --sign-key KEY_ID --full-if-older-than 30D --archive-dir /var/cache/backupninja/duplicity --include '/Users/nosmo/backupdir/' --exclude '**' / s3+http://my-backup/
Info: <<<< finished action etc/backup.d/example.dup: SUCCESS
Debug: send report to root
Info: FINISHED: 1 actions run. 0 fatal. 0 error. 0 warning.
nosmo@Hologram-Rose backupninja =) $ s3cmd la #shows no files created
nosmo@Hologram-Rose backupninja =) $ duplicity cleanup --force --s3-european-buckets --s3-use-new-style --no-print-statistics --ssh-options '' --encrypt-key KEY_ID --sign-key KEY_ID --full-if-older-than 30D --archive-dir /var/cache/backupninja/duplicity s3+http://my-backup/
Specified archive directory '/var/cache/backupninja/duplicity/02e017f45f73d304fffffc79694f8d2c' does not exist, or is not a directory
```
This isn't exactly a critical issue as not having this directory present could be considered a failed install, but having a check with a fatal error here makes the source of the issue clear to the user.1.1.0https://0xacab.org/liberate/backupninja/-/issues/11285MySQL handler is vulnerable to malicious identifiers2018-06-28T00:31:16ZJerome CharaouiMySQL handler is vulnerable to malicious identifiersBecause MySQL allows databases and tables names to include [arbitrary unicode characters](https://dev.mysql.com/doc/refman/5.5/en/identifiers.html), a malicous actor could obtain root execution on the system running the MySQL handler.
T...Because MySQL allows databases and tables names to include [arbitrary unicode characters](https://dev.mysql.com/doc/refman/5.5/en/identifiers.html), a malicous actor could obtain root execution on the system running the MySQL handler.
This is mitigated by the fact that database and/or table creation privileges are required for this to be exploited. Filesystem privileges might also be required, since the proof-of-concept I was able to produce is unable to execute a full command-line which includes spaces. But this could possibly be bypassed by some shell-foo I'm not currently privy to.
The Debian security team's evaluation of this issue is that the previous embargo on this issue is counter-productive due to the low estimated impact, hence this new public issue.
This specific issue was discovered and discussed while discussing a seperate, unrelated issue. [See this discussion thread for context](https://0xacab.org/riseuplabs/backupninja/issues/11278#note_134769).1.1.0Jerome CharaouiJerome Charaouihttps://0xacab.org/liberate/backupninja/-/issues/11272ninjahelper bug2020-09-01T16:20:15ZChimitninjahelper bugHi!
I just started using **backupninja** and faced with a problem in **ninjahelper**. I chose `sqldump` and `compress` options in the wizard, but when I finished creating the task and opened its config file I saw both options are set to...Hi!
I just started using **backupninja** and faced with a problem in **ninjahelper**. I chose `sqldump` and `compress` options in the wizard, but when I finished creating the task and opened its config file I saw both options are set to **no**:
```
| ### backupninja MySQL config file ### │
│ │
│ # hotcopy = < yes | no > (default = no) │
│ # make a backup of the actual database binary files using mysqlhotcopy. │
│ hotcopy = no │
│ │
│ # sqldump = < yes | no > (default = no) │
│ # make a backup using mysqldump. this creates text files with sql commands │
│ # sufficient to recontruct the database. │
│ # │
│ sqldump = no │
│ │
│ # sqldumpoptions = <options> │
│ # (default = --lock-tables --complete-insert --add-drop-table --quick --quote-names) │
│ # arguments to pass to mysqldump │
│ # sqldumpoptions = --add-drop-table --quick --quote-names │
│ │
│ # compress = < yes | no > (default = yes) │
│ # if yes, compress the sqldump output. │
│ compress = no
```
![Снимок_экрана_2017-05-11_в_14.22.53](/uploads/d129207ea62f596da1b7e2c1541c2b0a/Снимок_экрана_2017-05-11_в_14.22.53.png)1.2.0-rc1Jerome CharaouiJerome Charaouihttps://0xacab.org/liberate/backupninja/-/issues/594configure possibly broken on federa core 62018-01-05T15:53:37ZGhost Userconfigure possibly broken on federa core 6When i try to configure the latest tag i get:
<pre>
[root@testserver backupninja-0.9.5]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk.....When i try to configure the latest tag i get:
<pre>
[root@testserver backupninja-0.9.5]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for bash... /bin/bash
checking for sed... /bin/sed
checking for awk... /bin/awk
checking for md5sum... /usr/bin/md5sum
checking for rpm... yes
checking to see if we can redefine _topdir... yes
checking for rpm... (cached) yes
checking to see if we can redefine _topdir... yes
checking whether ln -s works... yes
configure: creating ./config.status
config.status: error: cannot find input file: Makefile.in
</pre>
works just fine with the 0.9.4 tag.
Cheers
Rune
*(from redmine: created on 2007-12-16, closed on 2010-01-27)*0.9.7https://0xacab.org/liberate/backupninja/-/issues/614backupninja mysql handler on non debian system2017-09-27T10:44:03Zanonymousbackupninja mysql handler on non debian systemI use normally Debian, but I was asked to support another linux system (CentOS). the mysql handler looks for /etc/mysql/debian.cnf which doesn't exist on centos. I have /etc/my.cnf only. I created the /etc/mysql/debian.cnf file and then ...I use normally Debian, but I was asked to support another linux system (CentOS). the mysql handler looks for /etc/mysql/debian.cnf which doesn't exist on centos. I have /etc/my.cnf only. I created the /etc/mysql/debian.cnf file and then it worked. However it would be nicer if it couldnt find this file that it just worked with an auto generated file from the dbusername/dbpassword in the 20.mysql config.
*(from redmine: created on 2008-09-09, closed on 2010-08-06)*0.9.8https://0xacab.org/liberate/backupninja/-/issues/617mysql handler should quote filenames2017-09-27T10:44:03Zanarcatmysql handler should quote filenamesThe mysql handler doesn't deal well with shell metacharacters in database names.
Therefore, we are having errors like this:
<pre>
jan 20 04:19:04 Warning: bash: 1: ambiguous redirect
jan 20 04:19:04 Warning: Failed to dump mysql ...The mysql handler doesn't deal well with shell metacharacters in database names.
Therefore, we are having errors like this:
<pre>
jan 20 04:19:04 Warning: bash: 1: ambiguous redirect
jan 20 04:19:04 Warning: Failed to dump mysql databases foo?blog
</pre>
Here's a simple patch to the mysql handler:
<pre>
--- mysql.orig 2009-01-20 10:31:17.000000000 -0500
+++ mysql 2009-01-20 10:32:09.000000000 -0500
@@ -281,9 +281,9 @@
fatal "Either you have an authentication problem, or mysqld doesn't appear to be running!"
fi
if [ "$compress" == "yes" ]; then
- execstr="$DUMP | $GZIP > $dumpdir/${db}.sql.gz"
+ execstr="$DUMP | $GZIP > '$dumpdir/${db}.sql.gz'"
else
- execstr="$DUMP -r $dumpdir/${db}.sql"
+ execstr="$DUMP -r '$dumpdir/${db}.sql'"
fi
fi
debug "su $user -c \"$execstr\""
</pre>
*(from redmine: created on 2009-01-20, closed on 2009-12-25)*0.9.7https://0xacab.org/liberate/backupninja/-/issues/618mysql error messages may clobber backups2017-09-27T10:44:03Zanarcatmysql error messages may clobber backupsI have yet to reproduce this or find a case where it is critical, but this code strikes me as a recipe for disaster:
<pre>
if [ "$compress" == "yes" ]; then
execstr="$DUMP | $GZIP > '$dumpdir...I have yet to reproduce this or find a case where it is critical, but this code strikes me as a recipe for disaster:
<pre>
if [ "$compress" == "yes" ]; then
execstr="$DUMP | $GZIP > '$dumpdir/${db}.sql.gz'"
else
execstr="$DUMP -r '$dumpdir/${db}.sql'"
fi
fi
debug "su $user -c \"$execstr\""
if [ ! $test ]
then
output=@su $user -c "$execstr" 2>&1@
</pre>
Here, if the dbs are compressed, the redirect will be something like this:
<pre>
mysqldump | gzip > foo.sql 2>&1
</pre>
Which means that errors will go to foo.sql. This is not what we want. Proof of my theory:
<pre>
anarcat@mumia [~]$ echo just to stdout
just to stdout
anarcat@mumia [~]$ ( echo to stderr >&2 )
to stderr
anarcat@mumia [~]$ ( echo to stderr >&2 ) > /dev/null
to stderr
anarcat@mumia [~]$ ( echo to stderr, returning to stdin >&2 ) > test 2>&1
anarcat@mumia [~]$ cat test
to stderr, returning to stdin
</pre>
This is bad, because any error from mysql will corrupt the sql dump.
*(from redmine: created on 2009-01-20, closed on 2010-01-08)*0.9.7https://0xacab.org/liberate/backupninja/-/issues/640If when parameter is set to a time, it will silently fail2018-01-10T10:00:23ZmicahIf when parameter is set to a time, it will silently failIf the when parameter is set like this:
when = 01:00
backupninja's isnow() function will take that time and consider it to be the 'whendayofweek' and will never match against anything. As a result, the backups will never run, and n...If the when parameter is set like this:
when = 01:00
backupninja's isnow() function will take that time and consider it to be the 'whendayofweek' and will never match against anything. As a result, the backups will never run, and no error is generated because every time backupninja runs, it thinks that the existing time does not match the time that backups should be run, so it decides not to run, every single time.
*(from redmine: created on 2009-03-09)*1.1.0micahmicahhttps://0xacab.org/liberate/backupninja/-/issues/845mysql handler not detect mysqldump errors2017-09-27T10:44:03ZGhost Usermysql handler not detect mysqldump errorsMySQL handler sometime produce broken backups, example from log:
Май 27 01:41:53 Debug: su root -c "/usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-tables --complete-insert --add-drop-table --quick --
quote-name...MySQL handler sometime produce broken backups, example from log:
Май 27 01:41:53 Debug: su root -c "/usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-tables --complete-insert --add-drop-table --quick --
quote-names example | /bin/gzip > /var/backup/spool/mysql/sqldump/example.sql.gz"
Май 27 01:44:18 Debug: mysqldump: Couldn't execute 'show create table `example_table`': SHOW VIEW command denied to user 'debian-sys-maint'@'localhost'
for table 'example_table' (1142)
Май 27 01:44:18 Info: Successfully finished dump of mysql database example
backupninja 0.9.4, Debian etch.
*(from redmine: created on 2009-05-26, closed on 2010-01-08)*0.9.7https://0xacab.org/liberate/backupninja/-/issues/1021include directory with space2018-01-05T15:53:37ZGhost Userinclude directory with spaceI try to do a rdiff backup of directory with a space in the include path.
I did try those method
include = /path/with/white space
include = /path/with/white\ space
include = "/path/with/white space"
Each time in the debug log i...I try to do a rdiff backup of directory with a space in the include path.
I did try those method
include = /path/with/white space
include = /path/with/white\ space
include = "/path/with/white space"
Each time in the debug log it try to backup white and space as two different path.
I did some search in your files and i saw that in the tools.in file at line 42 that you are escaping \ too much it should be ret="${ret//\*/__star__}".
It not solve the issue but it's maybe one step closer to the solution.
Thank's for the help.
Sorry for my english i'm not very good ;)
*(from redmine: created on 2009-06-29, closed on 2010-01-08)*0.9.7https://0xacab.org/liberate/backupninja/-/issues/1339/proc/ide/hd?/settings interface is obsolete2018-01-05T15:53:37Zalster/proc/ide/hd?/settings interface is obsolete<pre>
mybox kernel: [1246589.298815] Warning: /proc/ide/hd?/settings interface is obsolete, and will be removed soon!
</pre>
This message was seen on a lenny system running linux-image-2.6.26-2-686 and backupninja 0.9.6-4.
I see ...<pre>
mybox kernel: [1246589.298815] Warning: /proc/ide/hd?/settings interface is obsolete, and will be removed soon!
</pre>
This message was seen on a lenny system running linux-image-2.6.26-2-686 and backupninja 0.9.6-4.
I see the same code is still found in revision 78884142 of handlers/sys.in on lines 432/433:
432 STATUS="Gathering information about your ide drivers:"
433 catiffile "/proc/ide"
*(from redmine: created on 2009-10-18, closed on 2009-12-25)*0.9.6https://0xacab.org/liberate/backupninja/-/issues/1340pgsql handler does not report failed database dumps2018-01-05T15:53:37Zalsterpgsql handler does not report failed database dumps<pre>
Debug: su - postgres -c "/usr/bin/pg_dumpall | /bin/gzip > /var/backups/postgres/myserver-all.sql.gz"
Debug: pg_dump: [archiver (db)] connection to database "mydatabase" failed: FATAL: database "mydatabase" does not exist pg_dump...<pre>
Debug: su - postgres -c "/usr/bin/pg_dumpall | /bin/gzip > /var/backups/postgres/myserver-all.sql.gz"
Debug: pg_dump: [archiver (db)] connection to database "mydatabase" failed: FATAL: database "mydatabase" does not exist pg_dumpall: pg_dump failed on database "mydatabase", exiting
Info: Successfully finished dump of pgsql cluster
Info: <<<< finished action /etc/backup.d/20.pgsql: SUCCESS
</pre>
If I had not been running this pgsql backup handler in debug mode, I had not become aware of one of the databases not being dumped. It would be better if the whole process would exit with a non-zero status code if pd_dump failed to create just one of the dumps. Otherwise, you may end up with one database missing from your backups without the sysadmin ever becoming aware of it until she needs them.
I admit that this situation is somewhat constructed, though. I dropped the "mydatabase" by the time backupninja was creating the dumps. Nevertheless, there could be other resons for the database missing, or similar errors could occur and not get reported.
This is about backupninja 0.9.6-4 on Debian/GNU Linux 5.0.3 and postgresql 8.3.8-0lenny1.
*(from redmine: created on 2009-10-18, closed on 2010-01-08)*0.9.7https://0xacab.org/liberate/backupninja/-/issues/1571rdiff-backup warnings and errors are not reported2018-01-05T15:53:37Zalsterrdiff-backup warnings and errors are not reportedWe run rdiff-backup push-style backups with backupninja (backupninja is installed on the production server and instructs rduff-backup to back up our data to a remote backup server).
Reading the 'Statistics' section in rdiff-backup(1) an...We run rdiff-backup push-style backups with backupninja (backupninja is installed on the production server and instructs rduff-backup to back up our data to a remote backup server).
Reading the 'Statistics' section in rdiff-backup(1) and at http://rdiff-backup.nongnu.org/rdiff-backup.1.html we learnt that rdiff-backup creates a log file at destination:/path/to/backup-directory/rdiff-backup-data/backup.log which may contain very important information including reports on failed backups. These warnings and error messages are normally also returned to the terminal while rdiff-backup runs. However, it appears that backupninjas' rdiff-handler completely ignores this possibly important information and considers all backups to be successfull as long as the work environment on the remote server is correctly setup.
It would be good to at least transport back rdiff-backup log lines starting with "UpdateError" or "Warning:" to backupninjas' log facility.
I can provide an example rdiff-backup-data/backup.log via a non-public channel if this would help improving this. The common entries in the rdiff-backup backup log file are more or less documented on the rdiff-backup wiki at http://wiki.rdiff-backup.org/.
*(from redmine: created on 2010-01-18, closed on 2012-02-25)*1.0intrigeriintrigerihttps://0xacab.org/liberate/backupninja/-/issues/2052Mysqldump: Failed to dump mysql databases information_schema2017-09-27T10:44:03ZVaracMysqldump: Failed to dump mysql databases information_schemabackupninja --debug --now --run /etc/backup.d/10_all_databases.mysql
gives me:
@Debug: su root -c "/usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-tables --complete-insert --add-drop-table --quick --quote-nam...backupninja --debug --now --run /etc/backup.d/10_all_databases.mysql
gives me:
@Debug: su root -c "/usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-tables --complete-insert --add-drop-table --quick --quote-names information_schema -r /var/backups/mysql/sqldump/information_schema.sql"
Warning: mysqldump: Got error: 1044: Access denied for user 'root'@'localhost' to database 'information_schema' when using LOCK TABLES
Warning: Failed to dump mysql databases information_schema
@
/etc/backup.d/10_all_databases.mysql:
@dbhost = localhost
databases = all
backupdir = /var/backups/mysql
hotcopy = no
sqldump = yes
compress = no
configfile = /etc/mysql/debian.cnf
@
backupninja v. 0.9.6-4
mysql-client-5.1 v. 5.1.41-3ubuntu7
Using additional "--single-transaction" or "--lock-all-tables" instead of "--lock-tables" works:
@Debug: su root -c "/usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-tables --complete-insert --add-drop-table --quick --quote-names --single-transaction information_schema -r /var/backups/mysql/sqldump/information_schema.sql"
Info: Successfully finished dump of mysql database information_schema
Debug: su root -c "/usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-all-tables --complete-insert --add-drop-table --quick --quote-names information_schema -r /var/backups/mysql/sqldump/information_schema.sql"
Info: Successfully finished dump of mysql database information_schema
@
While debugging i found that the variable sqldumpoptions is ignored in /etc/backup.d/10_all_databases.mysql, and is hardcoded in /usr/share/backupninja/mysql, even if the current documentation lists the variable sqldumpoptions. It would be very useful to be able to pass options to mysqldump.
*(from redmine: created on 2010-03-25, closed on 2010-06-24)*0.9.8intrigeriintrigerihttps://0xacab.org/liberate/backupninja/-/issues/2077$duplicity_sub can't handle alphnum characters2018-01-05T15:53:37ZVarac$duplicity_sub can't handle alphnum charactersIn Ubuntu Lucid, duplicity comes in version 0.6.08b, which breaks the current method to analyse the sub-version. Nasty.
I use the Lucid version of backupninja, 0.9.6-4
<pre>
duplicity --version | /usr/bin/awk '{print $2}'
0.6.0...In Ubuntu Lucid, duplicity comes in version 0.6.08b, which breaks the current method to analyse the sub-version. Nasty.
I use the Lucid version of backupninja, 0.9.6-4
<pre>
duplicity --version | /usr/bin/awk '{print $2}'
0.6.08b
</pre>
<pre>
/usr/share/backupninja/dup: Zeile 99: [: 08b: Ganzzahliger Ausdruck erwartet.
/usr/share/backupninja/dup: Zeile 105: [: 08b: Ganzzahliger Ausdruck erwartet.
...
/usr/share/backupninja/dup: Zeile 166: [: 08b: Ganzzahliger Ausdruck erwartet.
/usr/share/backupninja/dup: Zeile 208: [: 08b: Ganzzahliger Ausdruck erwartet.
/usr/share/backupninja/dup: Zeile 228: [: 08b: Ganzzahliger Ausdruck erwartet.
</pre>
*(from redmine: created on 2010-03-28, closed on 2010-05-06)*0.9.8intrigeriintrigeri