openmediavault-backup - fdisk: cannot open /dev/

toxicdragon · 1. April 2020

Hello,

when trying to backup data using the openmediavault-backup plugin, the following error message ist shown:

Code

Error #0:
OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; /usr/sbin/omv-backup 2>&1': Method: ddfull
Device file:  /dev/mapper/root
Root drive: /dev/
fdisk: cannot open /dev/: Is a directory in /usr/share/openmediavault/engined/rpc/backup.inc:72
Stack trace:
#0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(588): OMVRpcServiceBackup->{closure}('/tmp/bgstatuseD...', '/tmp/bgoutputq1...')
#1 /usr/share/openmediavault/engined/rpc/backup.inc(74): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
#2 [internal function]: OMVRpcServiceBackup->doBackup(NULL, Array)
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): 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(537): OMV\Rpc\Rpc::call('Backup', 'doBackup', NULL, Array, 1)
#6 {main}

Alles anzeigen

This problem was actuatlly reported back in 2016 for OMV3: Openmediavault-backup errors

Info: I also use the openmediavault-sharerootfs plugin; maybe this causes a problem with the /dev/mapper/root folder? I use OMV 5.3.9-1

ryecoaaron · 1. April 2020

Zitat von toxicdragon

when trying to backup data using the openmediavault-backup plugin, the following error message ist shown:

I have tried to get root drive detection to work for years. Some setup like yours (using LVM or LUKS?) is just not going to work. That is why there is a root device override in the plugin form.

Zitat von toxicdragon

This problem was actuatlly reported back in 2016 for OMV3:

And if you read that post, I fixed it. Your problem is different.

Zitat von toxicdragon

nfo: I also use the openmediavault-sharerootfs plugin; maybe this causes a problem with the /dev/mapper/root folder?

Nope. That doesn't affect anything with the backup plugin. If findmnt -n / | awk '{ print $2 }' doesn't get the correct root device, you will have to specify the root device.

johanvandyck · 19. Mai 2021

Hi

I'm afraid he is not the only one: I use omv 5.6.7.1 and the rood devide is not found as well.

I tried it twith and without the the openmediavault-sharerootfs plugin. No change.Error #0:

Code

OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; /usr/sbin/omv-backup 2>&1': Method: fsarchiver
Device file:  /dev/mapper/terramaster--vg-root
Root drive: /dev/
fdisk: cannot open /dev/: Is a directory in /usr/share/openmediavault/engined/rpc/backup.inc:72
Stack trace:
#0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(588): OMVRpcServiceBackup->{closure}('/tmp/bgstatusbg...', '/tmp/bgoutputNm...')
#1 /usr/share/openmediavault/engined/rpc/backup.inc(74): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
#2 [internal function]: OMVRpcServiceBackup->doBackup(NULL, Array)
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): 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(537): OMV\Rpc\Rpc::call('Backup', 'doBackup', NULL, Array, 1)
#6 {main}

Alles anzeigen

your code findmnt -n / | awk '{ print $2 }' give me:

Code

root@openmediavault:/srv/dev-disk-by-label-vol1# findmnt -n / | awk '{ print $2 }'
/dev/mapper/terramaster--vg-root
root@openmediavault:/srv/dev-disk-by-label-vol1# ll /dev/mapper/terramaster--vg-root
lrwxrwxrwx 1 root root 7 May 18 21:43 /dev/mapper/terramaster--vg-root -> ../dm-0
root@openmediavault:/srv/dev-disk-by-label-vol1# findmnt -n -o SOURCE /
/dev/mapper/terramaster--vg-root
root@openmediavault:/srv/dev-disk-by-label-vol1# sudo cat /etc/fstab | grep '\s\/\s'
/dev/mapper/terramaster--vg-root /               ext4    noatime,nodiratime,errors=remount-ro 0 1
root@openmediavault:/srv/dev-disk-by-label-vol1#

What should I give as "root device" manually? /dev/mapper/terramaster--vg-root is working fine.

ryecoaaron · 19. Mai 2021

Zitat von johanvandyck

I'm afraid he is not the only one: I use omv 5.6.7.1 and the rood devide is not found as well.

I'm not going to try and make the plugin work with every non-standard setup. You are using LVM and that is non-standard. That is why the root override is there.

Zitat von johanvandyck

Root drive: /dev/

As you can see, the plugin is trying to get the root device of the LV and just getting /dev (which will never work). Without knowing your drive and volume group setup, I can't give exact info but setting root to /dev/sda (or whatever drive your grub setup is on) would be the best bet. The root device is only used to backup grub and partition info. The latter isn't real useful if you are using LVM.

johanvandyck · 19. Mai 2021

Hi

I don't blame anyone anything. It's just hard to find doc on the plugin what to put where.

I was not aware I'm using special setup: my debian is on an SSD with default layout. My data on a raid 1 volume consisting out of 2 disks, standard formatted with btfrs on the debian install process. I assume you refer to "btfrs" as "non standard LVM".

Am I correct the "/dev/terramaster-vg/root" is the root device I should fill in?

Code

root@openmediavault:/srv/dev-disk-by-label-vol1# lvscan
  ACTIVE            '/dev/terramaster-vg/root' [<27.94 GiB] inherit
  ACTIVE            '/dev/terramaster-vg/swap_1' [976.00 MiB] inherit
  ACTIVE            '/dev/terramaster-vg/home' [203.00 GiB] inherit

root@openmediavault:/srv/dev-disk-by-label-vol1# blkid
/dev/sda: UUID="a8a59497-5254-e264-7dcc-23d02864984c" UUID_SUB="91755205-6b7d-10fe-0c9a-5eb00b680f53" LABEL="terramaster:mirror1" TYPE="linux_raid_member"
/dev/md127: LABEL="vol1" UUID="b314241b-85fa-408e-96b9-d43c5e697c20" UUID_SUB="0d5c1ddc-5fbf-4325-86f4-3da3131e1bdc" TYPE="btrfs"
/dev/sdb: UUID="a8a59497-5254-e264-7dcc-23d02864984c" UUID_SUB="bb58e724-1d83-1049-b587-9a3a8d3135d1" LABEL="terramaster:mirror1" TYPE="linux_raid_member"
/dev/sdc1: UUID="8E1A-2580" TYPE="vfat" PARTUUID="e362a67d-151a-4e7f-9417-52eef9db46b6"
/dev/sdc2: UUID="2f060f8e-2d01-4b0c-a8d6-c8b446eed109" TYPE="ext2" PARTUUID="322f24ae-41ad-4596-8a0e-2ca054e4c4a2"
/dev/sdc3: UUID="D8MS0q-HFid-2sdu-0MJ3-1c8s-QJLb-pWC9Rr" TYPE="LVM2_member" PARTUUID="e8c969dc-dbb4-488b-98e8-833023ecdbbb"
/dev/mapper/terramaster--vg-root: UUID="46c3433f-08f3-4af7-94fe-029d5900370f" TYPE="ext4"
/dev/sdd1: UUID="6c89a123-0ecb-4f46-a0cb-abee74e19a2c" TYPE="ext4" PARTUUID="380f83d1-01"
/dev/mapper/terramaster--vg-home: UUID="6a2c88c6-2d65-4e03-a688-2d6080dc05f9" TYPE="ext4"

Alles anzeigen

Thanks!

Johan.

ryecoaaron · 19. Mai 2021

Zitat von johanvandyck

It's just hard to find doc on the plugin what to put where.

What needs to be documented? hard to document something that doesn't really work well with the plugin.

Zitat von johanvandyck

I was not aware I'm using special setup: my debian is on an SSD with default layout. My data on a raid 1 volume consisting out of 2 disks, standard formatted with btfrs on the debian install process. I assume you refer to "btfrs" as "non standard LVM".

I consider a standard setup to be what the OMV iso installs. I understand that you can do anything with the debian installer and that it will let you do LVM pretty easily but that is not what I consider standard for OMV. Raid, LVM, btrfs, etc for the OS disk are not standard. If someone wants to write a better backup plugin to support those, great. I just don't have plans to do that since the backup plugin is a pain in the ass to restore as it is.

Zitat von johanvandyck

Am I correct the "/dev/terramaster-vg/root" is the root device I should fill in?

raid and lvm... even more fun to the mix. No, If /dev/sdc is where grub is installed, then you would put /dev/sdc in for the root device. The problem is I wouldn't use the grub and partition backups for anything on your setup since they won't be enough to recreate raid and lvm setups.

johanvandyck · 19. Mai 2021

Hi

Thanks for the info.

For your info: in my setup I had a hard time to install "OMV iso" to a USB stick to put it on my terramaster NAS. I struggled with efi boot support, NIC 10gbit driver support and USB stick creation. So after a while I bought myself an USB enclosure with a SSD. A separate debian install with omv on top seems the most easy way to get the task done. The use of LVM on my OS? -> no particular reason. I can't remember why I choose it over ext4.

my /boot is indeed on /dev/sdc, a LVM volume.

Code

Disk /dev/sdc: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Generic
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8EE3F8F9-7C51-461D-889C-BE354D5F1144

Device       Start       End   Sectors   Size Type
/dev/sdc1     2048   1050623   1048576   512M EFI System
/dev/sdc2  1050624   2050047    999424   488M Linux filesystem
/dev/sdc3  2050048 488396799 486346752 231.9G Linux LVM

Alles anzeigen

johanvandyck · 19. Mai 2021

If someone struggles with backup & OS disk containing LVM: please have a look at https://www.howtoforge.com/linux_lvm_snapshots

It explains how to create a snapshot-backup and to restore.

Cheers

Johan.

ryecoaaron · 19. Mai 2021

Zitat von johanvandyck

my /boot is indeed on /dev/sdc, a LVM volume.

grub can't really boot from an LVM volume. That is why you have /dev/sdc2 as a normal filesystem for /boot. /dev/sdc3 is your LVM physical volume.

Agricola · 21. Mai 2021

Zitat von ryecoaaron

Raid, LVM, btrfs, etc for the OS disk are not standard. If someone wants to write a better backup plugin to support those, great. I just don't have plans to do that since the backup plugin is a pain in the ass to restore as it is.

I’m glad to see you say that. I tried the plugin a while back ( I didn’t try very hard) and never could get a working backup. No RAID, LVM, or btrfs here. Just vanilla. I’m happy to stay with dd.

ryecoaaron · 21. Mai 2021

Zitat von Agricola

’m happy to stay with dd.

If you use dd full on the plugin, I'm not sure what would be different than the dd command you are using.

Agricola · 21. Mai 2021

ryecoaaron honestly, I don’t know. Maybe something to do with it being a live backup. Like I said, I didn’t try very hard.

ryecoaaron · 21. Mai 2021

Zitat von Agricola

Maybe something to do with it being a live backup. Like I said, I didn’t try very hard.

When you are using dd, is the system running?

Agricola · 21. Mai 2021

ryecoaaron no. I shut the server down and run dd from my Mac or Linux machines.

ajaja · 28. Juni 2021

Zitat von Agricola

Like I said, I didn’t try very hard.

Reading this today put a big dumb smile on my face. Just wanted to let you know and say:
Thank you.

Agricola · 29. Juni 2021

Well, dd takes a few lines of code and it shuts your server down for about 30 minutes; double that if you make a physical backup to make sure it really works. It’s anything BUT automatic, but it ALWAYS works.

lknop · 16. November 2021

I am resurrecting an old thread, but it's not that old and it has been revived in the past already.

I stumbled on the same issue as OP did - due to the omv installer not able to partition the disk, I landed on pure debian and installed omv from deb. For convenience I opted for lvm, but this obiviously breaks the backup plugin. However, I was able to come up with a close equivalent so I am pasting it in case it can be useful for someone. My setup has separate boot and efi partitions, and omv root is on single logical volume.

I use fsarchiver to be able to restore to a different disk in case of failure. I know lvm is generally not supported, but it gives a great option to use snapshots for safe backups from an unmounted volume rather than forcing fsarchiver to backup live filesystem with -A flag.

Bash

#!/bin/sh

# config variables - adjust for your environment
backupdir=/srv/4tb/omvbackup
retaindays=10
volumegroup=omv-vg
volume=root
rootdevice=/dev/nvme0n1
efipartition=/dev/nvme0n1p1
bootpartition=/dev/nvme0n1p2

find ${backupdir} -maxdepth 1 -type f -mtime +${retaindays} -delete

date=$(date +"%Y%m%d_%H%M%S")

# clean apt-get cache to save space
apt-get clean

# clean openmediavault upload cache and recreate Packages file
rm -f /var/cache/openmediavault/archives/*
touch /var/cache/openmediavault/archives/Packages

mkdir -p ${backupdir}
lvcreate -L 1GB -s -n ${volume}_snap /dev/${volumegroup}/${volume}
fsarchiver savefs --exclude='/var/lib/docker/' ${backupdir}/${date}-${volume}.fsa /dev/${volumegroup}/${volume}_snap
lvremove -y /dev/${volumegroup}/${volume}_snap

mount -o remount,ro ${efipartition}
fsarchiver savefs ${backupdir}/${date}-efi.fsa ${efipartition}
mount -o remount,rw ${efipartition}

mount -o remount,ro ${bootpartition}
fsarchiver savefs --exclude='*.iso' ${backupdir}/${date}-boot.fsa ${bootpartition}
mount -o remount,rw ${bootpartition}

sfdisk -d ${rootdevice} > ${backupdir}/${date}-sfdisk.txt
pvscan > ${backupdir}/${date}-pv.txt
lvdisplay > ${backupdir}/${date}-lv.txt
blkid > ${backupdir}/${date}-blkid.txt

Alles anzeigen

openmediavault-backup - fdisk: cannot open /dev/

toxicdragon 1. April 2020

Jetzt mitmachen!

Version	7.0-32 (Sandworm)
Processor	AMD EPYC 7302P 16-Core Processor
Kernel	Linux 6.1.15-1-pve
Hardware	Dell R7515