openmediavault-backup fails with message 'Failed to execute command '

EruIluvatar · 29. August 2017

Hi everyone

I'm trying to make a backup of my config using the official openmediavault-backup plugin.
Didn't pass any special parameters like --exclude or anything.
The backup should be stored on a freshly partitioned 6TB HDD.

However it fails with the following message:

Spoiler anzeigen

Trying again leads to the same message with slightly different file list.

Any idea what's going wrong here?
Seems like it's trying to copy a file with no filename ''...

Cheers

EruIluvatar · 30. August 2017

I didn't find a solution to this problem so far...
If nobody has an answer I'm opening a bug report.

As a workaround I did a backup using borg which I can really recommend.
My system drive went from 4.3 GB to 1.4 GB with lz4 compression and deduplication, that really blew my mind!

If anybody needs a hint on how to do that:

Code

borg init /path/to/backup/location


# I used -C lz4 for more speed and less compression
sudo borg create -C zlib,6 /path/to/backup/location::{hostname}-root-{now:%Y-%m-%d} / --one-file-system -p -v -s

ryecoaaron · 31. August 2017

Zitat von EruIluvatar

I didn't find a solution to this problem so far...
If nobody has an answer I'm opening a bug report.

It had a problem finding the root drive. What is the output of blkid

EruIluvatar · 31. August 2017

Code

/dev/sda1: UUID="0647cc14-0a19-e514-9be3-1268ccc95f0d" UUID_SUB="34ad2375-d687-4b8b-20c2-d12c447dd5f0" LABEL="homeserver:0" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="fdad7612-fd75-4f5d-ab69-049cee88efe0"
/dev/sdb1: UUID="0647cc14-0a19-e514-9be3-1268ccc95f0d" UUID_SUB="3ed0dfeb-e9cb-c522-53a3-98f6370d7d2a" LABEL="homeserver:0" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="fdad7612-fd75-4f5d-ab69-049cee88efe0"
/dev/sdc1: UUID="0647cc14-0a19-e514-9be3-1268ccc95f0d" UUID_SUB="113d1425-dedb-e33f-f4a9-3d0ec84a116d" LABEL="homeserver:0" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="fdad7612-fd75-4f5d-ab69-049cee88efe0"
/dev/sdd1: UUID="BC9C-706E" TYPE="vfat" PARTUUID="f20855cc-df4d-42ed-b82e-0e19158acbfb"
/dev/sdd2: UUID="5c908f0f-9b72-4de6-9006-61b74812222f" UUID_SUB="8ba93e0d-9ebc-4a49-ac89-22a8353330f6" TYPE="btrfs" PARTLABEL="System SSD" PARTUUID="565a8199-ca52-4e59-920d-45db9226c0f0"
/dev/sdd3: UUID="493c67bb-0cb9-45ac-87e6-1755fb5c7d18" TYPE="swap" PARTUUID="da08d50c-bc45-466a-9001-dcebd7e4441a"
/dev/sde1: UUID="0647cc14-0a19-e514-9be3-1268ccc95f0d" UUID_SUB="1f7b2116-8b96-e165-b293-471c722589d3" LABEL="homeserver:0" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="fdad7612-fd75-4f5d-ab69-049cee88efe0"
/dev/md0: UUID="afae0bad-6794-4af1-88df-cd47ffce1440" TYPE="crypto_LUKS"
/dev/mapper/md0-crypt: LABEL="BigMama" UUID="ae76bfba-d93f-43fe-b7cf-9d59506a250f" UUID_SUB="13c44b8d-63d1-4dc6-985a-9bb9f5ecccb4" TYPE="btrfs"
/dev/sdf1: LABEL="BigBackup" UUID="ad8e59f8-571d-4f87-9203-0498d641c1c9" TYPE="ext4" PARTUUID="a0453543-fc1e-4163-8990-3c5521e0bceb"

/dev/sdd is the root drive.
I seriously doubt it didn't find the root drive. The backup stopped when ~50Mb of data was already copied...

However it seem's like the fstab got messed up in a way. The "Sebi_ExFAT" drive seems mounted although it was an external USB drive that is not connected (and the NAS was rebooted since).
Also that it's mounted as type btrfs makes no sense, it was ExFAT.

Output of mount -l | grep /dev/sdd

Code

/dev/sdd2 on / type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@)
/dev/sdd2 on /export/Sebi_ExFAT type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
/dev/sdd1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sdd2 on /.snapshots type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=271,subvol=/@snapshots)
/dev/sdd2 on /home type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=269,subvol=/@home)
/dev/sdd2 on /home/.snapshots type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=272,subvol=/@home-snapshots)
/dev/sdd2 on /var/lib/docker/btrfs type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/var/lib/docker/btrfs)
/dev/sdd2 on /export/Sebi_ExFAT type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
/dev/sdd2 on /media/C4E3-170C type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
/dev/sdd2 on /export/Sebi_ExFAT type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
/dev/sdd2 on /media/C4E3-170C type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
/dev/sdd2 on /export/Sebi_ExFAT type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
/dev/sdd2 on /media/C4E3-170C type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)

Alles anzeigen

ryecoaaron · 1. September 2017

Zitat von EruIluvatar

I seriously doubt it didn't find the root drive. The backup stopped when ~50Mb of data was already copied...

Thanks for doubting the guy who wrote the code... It definitely didn't find the root drive in the line of code that tries to copy the mbr from the root drive. The backup worked but the mbr copy (a dd command) failed. Rysnc can use the path / where the dd command needs the actual drive (/dev/sdd). The function doesn't work with btrfs (or exfat) because OMV uses ext4 for the root drive on standard installs which is all I want to support.

EruIluvatar · 2. September 2017

Alright makes perfect sense. I just realized my root drive isn't even listed as 'Referenced' in the File Systems view.

tux1337 · 12. November 2017

Hi guys,

I've the same issue with another configuration.
My system is fully encrypted with luks (root partion also).

When I try to make a backup with openmediavault-backup extension, the rsync part is successfully done. Then dd of the root partition throws the error:

Code

Root drive: dd: failed to open '': No such file or directory

Issue is maybe the same: root partition is not recognized correctly.

Configuration:

MBR: /dev/vda
Encryption partition (LUKS) for root: /dev/vda1
root partition /dev/mapper/vda1-crypt

blkid:

Code

/dev/mapper/vda1-crypt: UUID="f674036b-aa8e-49c5-8912-87dfdf35e448" TYPE="ext4"
/dev/vda1: UUID="f4c663a2-1f50-48b8-99bb-a187c8fce390" TYPE="crypto_LUKS" PARTUUID="c0e211b5-01"
/dev/vda5: UUID="4302a071-6ba4-4ab8-83c6-a08d680c00c8" TYPE="ext4" PARTUUID="c0e211b5-05"
/dev/vdb: UUID="fa683cb3-523a-4c78-a509-035e74581fcd" TYPE="crypto_LUKS"
/dev/sr0: UUID="2017-10-07-13-20-04-00" LABEL="d-live 9.2.0 gn amd64" TYPE="iso9660" PTUUID="10969f64" PTTYPE="dos"
/dev/vdc: UUID="b52e55e9-a17b-49eb-9d1e-8772c4ab7e95" TYPE="crypto_LUKS"
/dev/sda: UUID="047f12f2-5b37-4366-8bf4-0712c02e9d44" TYPE="crypto_LUKS"
/dev/mapper/sda-crypt: LABEL="backup" UUID="5844538795724956145" UUID_SUB="7077405565985440678" TYPE="zfs_member"
/dev/mapper/vdb-crypt: LABEL="data" UUID="15441237811974705261" UUID_SUB="12513600626665205360" TYPE="zfs_member"
/dev/mapper/vdc-crypt: LABEL="data" UUID="15441237811974705261" UUID_SUB="9309010814859507645" TYPE="zfs_member"

Is this a valid configuration you want to support? Would be nice if you could support encrypted root partitions.

Thank you for your support.

ryecoaaron · 12. November 2017

Zitat von tux1337

Is this a valid configuration you want to support? Would be nice if you could support encrypted root partitions.

I need to just remove the mbr copy (which is what is failing on your system) on systems like yours. It wouldn't help recreate your setup anyway. Just out of curiosity, why are you encrypting the OS?

godfuture · 13. November 2017

hey guys, same issue for me here. I did not encrypt my installation with luks, but I installed omv on lvm on mdadm.

Is there any solution?

ryecoaaron · 14. November 2017

Zitat von godfuture

Is there any solution?

Same solution as mentioned above. I just want to remind everyone that I can't (and don't want to) support every configuration possible. If you choose to run a non-standard install, it is going to cause issues.

godfuture · 14. November 2017

Zitat von ryecoaaron

I need to just remove the mbr copy (which is what is failing on your system) on systems like yours. It wouldn't help recreate your setup anyway. Just out of curiosity, why are you encrypting the OS?

~~You mean "remove the mbr copy"? If yes, could you shortly explain more detailed? I know what is mbr, but I am confused why there should be copies of mbr...sooorry!!~~

Too stupid to read...dd is used to make a copy of my mbr. Okay. Does my setup break the way my root drive (ext4 on lvm on mdadm) is detected?

OFFTOPIC: Understoot your statement! Focus is important for every project. But pleeease please be aware that server installations on a single drive are not as safe as with raid. Sure backup is possible. But without raid, my server is down till I have restored on new disk.

Thanks a lot for your time! Love OMV already

ryecoaaron · 14. November 2017

Zitat von godfuture

Does my setup break the way my root drive (ext4 on lvm on mdadm) is detected?

Yep. The code looks at the inode number of the / directory and compares it to each device in the output of blkid. This is the best way I could come up to find which mbr to copy.

Zitat von godfuture

But pleeease please be aware that server installations on a single drive are not as safe as with raid. Sure backup is possible. But without raid, my server is down till I have restored on new disk.

I don't use raid for the OS drive on any of my servers. That is a false sense of security you have. Raid only protects your setup if you have a drive fail. If you accidentally delete a directory, it is deleted instantly on both drives. With the backup plugin backup, I could have my servers restored in probably 20 minutes. The whole idea of OMV is that nothing important is on the OS drive. If you make a backup whenever you change something fairly major, then it shouldn't hurt if it is a few weeks old.

tux1337 · 14. November 2017

Zitat von ryecoaaron

Just out of curiosity, why are you encrypting the OS?

On my root drive are key files for data encryption that is used to make an encrypted backup "to the cloud", so it makes sense to decrypt the root drive in this case.

May I suggest a solution?

It would solve the problem for the various configurations if you could add a new field to the omv-backup interface which the administrator can choose the drive for the MBR.
The field could be prefilled by your exisiting algorithm to find out the root drive - but could be overwritten by the administrator if it not fit.

What do you mean?

ryecoaaron · 14. November 2017

Zitat von tux1337

It would solve the problem for the various configurations if you could add a new field to the omv-backup interface which the administrator can choose the drive for the MBR.
The field could be prefilled by your exisiting algorithm to find out the root drive - but could be overwritten by the administrator if it not fit.

I left this out because it would complicate the plugin and a lot of people wouldn't know what the correct drive is. I guess I could add a text field that would override the calculated value. Most people wouldn't have to put anything in the text field.

tux1337 · 15. November 2017

Zitat von ryecoaaron

I left this out because it would complicate the plugin and a lot of people wouldn't know what the correct drive is. I guess I could add a text field that would override the calculated value. Most people wouldn't have to put anything in the text field.

This would fix it. Would be really nice if you could do this

ryecoaaron · 15. November 2017

Zitat von tux1337

This would fix it. Would be really nice if you could do this

3.7 in the repo now *might* have an extra field

tux1337 · 15. November 2017

Zitat von ryecoaaron

3.7 in the repo now *might* have an extra field

Works like a charm! Really good. Thank you very much. My configuration works now fine.

Jetzt mitmachen!