#2163 Issue closed: Backup 0 bytes if encryption enabled with empty openssl password

Labels: support / question, fixed / solved / done

chumunga opened issue at 2019-06-26 23:35:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):
    [root@it-cnt7 ~]# rear -V
    Relax-and-Recover 2.4 / Git

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
    NAME="CentOS Linux"
    VERSION="7 (Core)"

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
    sites.conf and tried local.conf

OUTPUT=ISO
BACKUP=NETFS
BACKUP_PROG=tar
BACKUP_TYPE=incremental
FULLBACKUPDAY="Mon"
FULLBACKUP_OUTDATED_DAYS=5
BACKUP_INTEGRITY_CHECK=1
BACKUP_PROG_CRYPT_ENABLED=1
BACKUP_PROG_CRYPT_KEY=test
BACKUP_PROG_CRYPT_OPTIONS="/usr/bin/openssl enc -aes256 -salt -k"
BACKUP_PROG_DECRYPT_OPTIONS="/usr/bin/openssl enc -aes256 -d -k"
BACKUP_URL=cifs://192.168.1.200/backups
BACKUP_OPTIONS="cred=/root/.cifs_pass,vers=1.0"

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
    VM, however i've had this issues on a standard PC and somehow the issue went away.

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    x86

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    BIOs

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    NAS

  • Description of the issue (ideally so that others can reproduce it):
    First, i've had this issue before I thought the solution was to change my encryption option from -aes-256-cbc to -aes256, that was not the reason. It is clear to me now i just got lucky with something which i don't know wha. However, if I comment out all the Crypt settings, everything works fine and I will see the "Archived file counter" showing how many files been archived and at what rate.

  • Workaround, if any:
    unless you know one.

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
    Here is the command rear -v mkbackuponly > test2.log

Relax-and-Recover 2.4 / Git
Using log file: /var/log/rear/rear-it-cnt7.113056.log
No full backup found (YYYY-MM-DD-HHMM-F.tar.gz) triggers full backup
Performing full backup using backup archive '2019-06-26-1609-F.tar.gz'
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Creating disk layout
Using guessed bootloader 'EFI' (found in first bytes on /dev/sda)
Encrypting backup archive with key defined in variable $BACKUP_PROG_CRYPT_KEY
Creating tar archive '/tmp/rear.I1DbZaO30tGzKwQ/outputfs/it-cnt7/2019-06-26-1609-F.tar.gz'
Preparing archive operationOK
Saving /var/log/rear/rear-it-cnt7.113056.log as /var/log/rear/rear-it-cnt7.log
Exiting rear mkbackuponly (PID 113056) and its descendant processes
Running exit tasks
You should also rm -Rf /tmp/rear.I1DbZaO30tGzKwQ

Which looks good, but the backup file outpiut is 8 bytes.

jsmeix commented at 2019-06-27 08:34:

@chumunga
we need a debug log file from you for "rear -D mkbackuponly"
plus the separated backup log file which is usually named backup.log
that gets also output where the backup and ISO are,
i.e. to the BACKUP_URL network location.

Does it perhaps work with "rear -D mkbackup"?
I have the dim feeling that the BACKUP_PROG_CRYPT stuff
may only work with the full "mkbackup" workflow
but not with the shortened "mkbackuponly" workflow.

I wonder why you wrote Backup.iso 0 bytes because I think with

OUTPUT=ISO
BACKUP=NETFS

you should get two separated files backup.tar.gz and HOSTNAME.iso
but not a Backup.iso file?

chumunga commented at 2019-06-28 17:38:

Hi jsmeix

We can resolve this ticket linking to
Backup tar file 0 bytes if encryption enabled with empty openssl password
https://github.com/rear/rear/issues/2157#issuecomment-506496775

Sorry for reopening, I didn't know I could actually reopen a closed ticket.

For future readers, the issue in this case was the password started with a $SomePassHere, which was being interpreted as a variable an empty one at that. Thus openssl was passed a blank password and it will create a file with 0 bytes. see link above for more details.

[Export of Github issue for rear/rear.]