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

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

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

      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:
      Display Spoiler


      Error #0:
      exception 'OMV\ExecException' with message 'Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; omv-mkconf backup 2>&1': sending incremental file list
      etc/openvpn/ipp.txt
      home/stefan/.config/syncthing/index-v0.14.0.db/001329.log
      var/cache/openmediavault/archives/
      var/cache/openmediavault/archives/Packages
      var/cache/samba/lck/
      var/cache/samba/msg/
      var/lib/emby-server/logs/server-63639561600.txt
      var/lib/monit/state
      var/lib/nginx/fastcgi/1/
      var/lib/nginx/fastcgi/1/03/
      var/lib/php5/sessions/
      var/lib/php5/sessions/sess_bnnbd64bn3ld2sj1ui70td0fc2
      var/lib/php5/sessions/sess_rcl9mbeu5aapk67rqfv38mi404
      var/lib/rrdcached/journal/rrd.journal.1504010435.221046
      var/log/auth.log
      var/log/daemon.log
      var/log/openvpn-status.log
      var/log/syslog
      var/log/tallylog
      var/log/nginx/[REDACTED]_access.log


      sent 17,601,167 bytes received 23,640 bytes 952,692.27 bytes/sec
      total size is 12,274,159,785 speedup is 696.41
      Root drive:
      dd: failed to open '': No such file or directory' in /usr/share/openmediavault/engined/rpc/backup.inc:72
      Stack trace:
      #0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(528): OMVRpcServiceBackup->{closure}('/tmp/bgstatusle...', '/tmp/bgoutputiF...')
      #1 /usr/share/openmediavault/engined/rpc/backup.inc(75): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
      #2 [internal function]: OMVRpcServiceBackup->doBackup(NULL, Array)
      #3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
      #4 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('doBackup', NULL, Array)
      #5 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('Backup', 'doBackup', NULL, Array, 1)
      #6 {main}


      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
    • 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:

      Source Code

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

      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
      omv 4.0.11 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • Source Code

      1. /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"
      2. /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"
      3. /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"
      4. /dev/sdd1: UUID="BC9C-706E" TYPE="vfat" PARTUUID="f20855cc-df4d-42ed-b82e-0e19158acbfb"
      5. /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"
      6. /dev/sdd3: UUID="493c67bb-0cb9-45ac-87e6-1755fb5c7d18" TYPE="swap" PARTUUID="da08d50c-bc45-466a-9001-dcebd7e4441a"
      7. /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"
      8. /dev/md0: UUID="afae0bad-6794-4af1-88df-cd47ffce1440" TYPE="crypto_LUKS"
      9. /dev/mapper/md0-crypt: LABEL="BigMama" UUID="ae76bfba-d93f-43fe-b7cf-9d59506a250f" UUID_SUB="13c44b8d-63d1-4dc6-985a-9bb9f5ecccb4" TYPE="btrfs"
      10. /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

      Source Code

      1. /dev/sdd2 on / type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@)
      2. /dev/sdd2 on /export/Sebi_ExFAT type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
      3. /dev/sdd1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
      4. /dev/sdd2 on /.snapshots type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=271,subvol=/@snapshots)
      5. /dev/sdd2 on /home type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=269,subvol=/@home)
      6. /dev/sdd2 on /home/.snapshots type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=272,subvol=/@home-snapshots)
      7. /dev/sdd2 on /var/lib/docker/btrfs type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/var/lib/docker/btrfs)
      8. /dev/sdd2 on /export/Sebi_ExFAT type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
      9. /dev/sdd2 on /media/C4E3-170C type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
      10. /dev/sdd2 on /export/Sebi_ExFAT type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
      11. /dev/sdd2 on /media/C4E3-170C type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
      12. /dev/sdd2 on /export/Sebi_ExFAT type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
      13. /dev/sdd2 on /media/C4E3-170C type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=268,subvol=/@/media/C4E3-170C)
      Display All
    • EruIluvatar wrote:

      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.
      omv 4.0.11 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • 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:

      Source Code

      1. 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:

      Source Code

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

      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?
      omv 4.0.11 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • godfuture wrote:

      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.
      omv 4.0.11 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • New

      ryecoaaron wrote:

      tux1337 wrote:

      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?

      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 :)
      Intel Pentium G3460T @ 3GHz
      Debian GNU/Linux 9.2 (stretch)
      Release: 4.0.10-1 Arrakis

      The post was edited 1 time, last by godfuture ().

    • New

      godfuture wrote:

      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.

      godfuture wrote:

      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.
      omv 4.0.11 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • New

      ryecoaaron wrote:

      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?
    • New

      tux1337 wrote:

      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.
      omv 4.0.11 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • New

      tux1337 wrote:

      This would fix it. Would be really nice if you could do this
      3.7 in the repo now *might* have an extra field :)
      omv 4.0.11 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!