How to restore OMV 4.X from backup-plugin to system SSD

Quote from omvnj2323

Trying to move from running OMV 5.5.23-1(Usul) on USB thumb drive, back to hard drive, with no success.

I'm currently running OMV 5 on a USB thumb drive. I've tried many ways to backup / restore to a sas hard drive in the server. Every method I try results in this upon trying to boot to the sas drive after the restore.

**Note, fsarchver works if restoring to another USB thumb drive, but not hard disk**

I've tried backing up / restoring using fsarchiver

I've tried installing fresh OMV 5 on the sas drive, then restoring just the primary partition using fsarchiver

I've tried using dd to create a direct clone from the USB to the SAS drive

I've tried a direct clone with clonezilla to the sas drive

I've tried an rsync backup, then restoring over the top of a fresh OMV 5 install on the sas drive.

All methods give the result above.

The grub bootloader starts, then when it starts to boot, I get (initramfs)

I've tried running fsck /dev/sdc1 but it wants confirmation to try to rewrite a countless number of blocks, I keep hitting y but I've not reached the end, so I gave up on that.

I can post all the exact commands I'm running, but I'm pretty sure they're all run correctly. My guess is that it is something to do with the 2 different media types. I'm hoping someone knows what to do.

note the change in /dev/sdc1 and /dev/sdb1 as these screenshots were taken between different retries, but it's the same drive.

Actually here are some of the commands I've run:

fsarchiver restore:

fsarchiver restfs /mnt/6TBbackup/OMVBackup/omvbackup/backup-omv-21-Jan-2021_10-59-06.fsa id=0,dest=/dev/sda1

clone with DD:

dd if=/dev/sdn of=/dev/sda bs=16M status=progress

Restore of Rsync backup taken with the backup plugin:

I ran this command while running the live OMV on the USB, restored over the fresh install of OMV 5 on the sas drive

I first formatted the sas drive partition that was created during the OMV 5 install

mkfs.ext4 /dev/sda1

then ran

rsync -aAXv --delete --exclude="lost+found" /srv/dev-disk-by-label-6TBBackup/OMVBackup/RsyncBackup/omvbackup/ /srv/dev-disk-by-uuid-d77fff66-c483-43d5-b0a5-cceef188de57/

Display More

Issue resolved. It ended up being that another SATA drive, connected to the same controller as the SAS drive, had a partition with the SAME UUID as the root partition I was restoring. This was the actual issue all along. I didn' t think it was an issue because the UUID on the USB stick matched as well, but I guess it didn't matter when booting to USB.

In my first attempt to test the restore process, I was using this SATA drive. Grub was not restored / installed correctly on this SATA drive, after restoring the dd portion of the backup, which contains the MBR and partition table, so it was not bootable. I just ended up leaving the SATA drive as is was, after that first attempt, and then added the SAS drive, which I decided would be the permanent boot drive.

When I eventually resolved the issue, I actually changed 2 things, so I didn't pinpoint the root cause.

I booted to systemrescuecd and took an fsarchvier backup of the USB stick

• I restored the new fsarchver backup to the SAS drive
• I also cleared the partitions off that SATA drive before I rebooted.

I initially thought there was an issue where something was not being backed up correctly, by using the backup plugin on the live running OS, and that instead running the backup from the liveCD resolved the issue. But that was not the case. I kind of knew in the back of my mind that the partition had been sitting on that SATA drive, but didn't think it was a problem because the partition UUID on the USB stick also matched, and it was not an issue booting from USB. But it did matter with the 2 hard disks matching, when trying to boot from hard disk. This explains why I could restore my original backups to another USB or a VM and boot without any issue. I reproduced this by simply restoring the dd portion of the backup to the sata drive again, which restores the partition table and UUID, without any data, and upon reboot, it reproduced the broken boot issue where boot halted at initramfs

This is due to my somewhat noobness with linuxI will not make this mistake again!

Quote from omvnj2323

Issue resolved. It ended up being that another SATA drive, connected to the same controller as the SAS drive, had a partition with the SAME UUID as the root partition I was restoring.

This is what can happen when you bit for bit clone a drive and try to use both in the same machine.

Thanks for the guide, but i still seem to struggle. Sorry for the noob questions.....

I have OMV 5.x and have it installed on 223 GB SSD and want it to replace it with 60 GB SSD because it is a bit of a overkill. I first tried it with Clonezilla but after several fails I gave up. (yes made sure that the partition fitted the 60 GB SSD).

I used fsarchiver to backup OMV.

When I restore the backup to the 60GB SSD drive it won't boot afterwards.

This is the lsblk output from my 223 GB SSD drive:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 223.6G  0 disk
|-sda1   8:1    0    41G  0 part /
|-sda2   8:2    0     1K  0 part
`-sda5   8:5    0    12G  0 part
sdb      8:16   0   1.8T  0 disk
`-sdb1   8:17   0   1.8T  0 part /srv/dev-disk-by-label-media

So what did I do:

I installed using a USB Stick OMV 5.x on the new clean 60 GB drive. Started it up and installed the SystemRescueCD om OMV and rebooted in to it.

mounted the sdb1 disk where the fsarchiver backup is saved.

The questions I have:

• When you do dd if=/mnt/YOUSHOULDKNOW/backup.grubparts of=/dev/YOUSHOULDKNOW, is the YOUSHOULDKNOW of the destination drive (in my case the 60 GB SSD) /dev/SDA of /dev/SDA1?
• When is used the dd command I did with /dev/SDA, should I then see the same partition table of my 223 GB SSD drive?
• The same goes for when using the fsarchiver command, to what partition should it restore, I assume SDA1?

I think my problem has to do with different sized disks however I changed the partition size to fit on the 60 GB SSD.

Is there not a way to install a fresh installation of OMV and then restore the configuration files and such?

All help is welcome.

Francis

Quote from francis

Thanks for the guide, but i still seem to struggle. Sorry for the noob questions.....

I have OMV 5.x and have it installed on 223 GB SSD and want it to replace it with 60 GB SSD because it is a bit of a overkill. I first tried it with Clonezilla but after several fails I gave up. (yes made sure that the partition fitted the 60 GB SSD).

I used fsarchiver to backup OMV.

When I restore the backup to the 60GB SSD drive it won't boot afterwards.

This is the lsblk output from my 223 GB SSD drive:

Code

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 223.6G  0 disk
|-sda1   8:1    0    41G  0 part /
|-sda2   8:2    0     1K  0 part
`-sda5   8:5    0    12G  0 part
sdb      8:16   0   1.8T  0 disk
`-sdb1   8:17   0   1.8T  0 part /srv/dev-disk-by-label-media

So what did I do:

I installed using a USB Stick OMV 5.x on the new clean 60 GB drive. Started it up and installed the SystemRescueCD om OMV and rebooted in to it.

mounted the sdb1 disk where the fsarchiver backup is saved.

The questions I have:

• When you do dd if=/mnt/YOUSHOULDKNOW/backup.grubparts of=/dev/YOUSHOULDKNOW, is the YOUSHOULDKNOW of the destination drive (in my case the 60 GB SSD) /dev/SDA of /dev/SDA1?
• When is used the dd command I did with /dev/SDA, should I then see the same partition table of my 223 GB SSD drive?
• The same goes for when using the fsarchiver command, to what partition should it restore, I assume SDA1?

I think my problem has to do with different sized disks however I changed the partition size to fit on the 60 GB SSD.

Is there not a way to install a fresh installation of OMV and then restore the configuration files and such?

All help is welcome.

Francis

Display More

Same here.

It's impossible to restore from fsarchiver. Even with same disk size in my case. Tried everything with no luck, that includes removing all partitions from my boot device and dding the grubpart file.

Thanks for the guide!

My openmediavault server's ssd disk died, and I replaced it with a new one (different brand, same capacity). Now I wanted to restore my last backup made with fsarchiver via the omv backup plugin, and I'm following the guide. After following the first 13 steps, I'm stuck with the last 2, where the critical things are done.

These were the partitions on my new ssd nvme disk before trying to restore (I had installed OMV on it):

Device         Boot     Start       End   Sectors   Size Id Type
/dev/nvme0n1p1           2048 486395903 486393856 231.9G 83 Linux
/dev/nvme0n1p2      486397950 488396799   1998850   976M  5 Extended
/dev/nvme0n1p5      486397952 488396799   1998848   976M 82 Linux swap / Solaris

After I ran the "restore grub and the partition table" step:

dd if=/mnt/array/Backup/omvbackup/backup-omv-30-ago-2021_03-00-01.grubparts of=/dev/nvme0n1

Now it looks like this:

Device         Boot Start       End   Sectors   Size Id Type
/dev/nvme0n1p1          1 488397167 488397167 232.9G ee GPT

And when I try to restore the main partition:

fsarchiver restfs backup-omv-30-ago-2021_03-00-01.fsa id=0,dest=/dev/nvme0n1p1

I get the following error:

oper_restore.c#152,convert_argv_to_strdicos(): "/dev/nvme0n1p1" is not a valid block device

So I think I messed the partition table. Maybe the grubparts are not written to /dev/nvme0n1 but to other place? Before trying to restore the partition table I could see GRUB installed with:

dd bs=512 count=1 if=/dev/nvme0n1 2>/dev/null | strings

But I can't see that anymore.

Had a not even 1year old crucial MX500 SSD 250gb as my omv system drive die on me and had a chance to test ryecoaarons backup plugin. Had regular fsarchiver backups of my entire system drive on my mergerFS filesystem.

Inserted a new system SSD, reinstalled OMV (not sure if necessary, but went quick), booted systemrescuecd from a different usb drive and then restored according to the instructions on page 1. Rebooted, everything works as if the SSD never failed. Thanks for the plugin and your work! Took like half an hour. Great

I just have one question, maybe because i don't understand EFI booting or GPT. Why is the dd of the .grubparts file necessary? Doesn't fsarchiver restore the full partition? I don't have a seperate boot partition, just /dev/sdc1 as boot and file partition for OMV and a swap partition.

Hello!

how are you?

My OMV its works fine, version 5.x, with backup plugin installed. OMV is installed on server only, without Virtual Machine.

So, follow the steps with fsarchiver on OMV GUI. The directory to put the backup files is our disk backup.

The backup process went well. After this I did use rsync to send/copy the files to ssd usb driver. Then, get other machine with a new disk, formated in ext4 gpt. Run live system, plug the ssd usb, mount the devices and go...

so.....

I did follow the steps about.
dd if=/mnt/YOUSHOULDKNOW/backup.grubparts of=/dev/YOUSHOULDKNOW

OK!

15 - Extract the backup to that drive (and correct partition): fsarchiver restfs backup.fsa id=0,dest=/dev/YOUSHOULDKNOW

(id=0 means that just the first filesystem from the backup will be restored. I am assuming that you did just backup one filesystem with one backup.)

Right, ok!

But, after reboot system, the system does not UP. Seems cannot get grub, or run grub. when I check with live cd system, all system files there, all directories. I check the smb.conf file and right, the same file that is run on the server production.

Please, How can I fix this.

Somebody can Help

Thanks

Douglas

Quote from bvrulez

My hardware setup is

7 - Check your RAID array: mdadm -D /dev/YOUSHOULDKNOW
8 - My array was running fine.
9 - Make a mountpoint in /mnt: mkdir /mnt/YOUSHOULDKNOW
10 - Mount array to mountpoint: mount /dev/YOUSHOULDKNOW /mnt/YOUSHOULDKNOW
11 - Move to backup directory on array
12 - Check your backup: fsarchiver archinfo backup.fsa

(Find out source partition, in my case the backup did not include the swap-partition, so I was pretty sure to backup just TO the first partition of my system disk)

13 - Find out what device name the disk has you want to install the files from the backup on: blkid
14 - This I did not do, but is recommended: If you are restoring to a new disk, write the backup of grub and the partition table (.grubparts file) to the disk before the fsarchiver restfs step with:

dd if=/mnt/YOUSHOULDKNOW/backup.grubparts of=/dev/YOUSHOULDKNOW

15 - Extract the backup to that drive (and correct partition): fsarchiver restfs backup.fsa id=0,dest=/dev/YOUSHOULDKNOW

(id=0 means that just the first filesystem from the backup will be restored. I am assuming that you did just backup one filesystem with one backup.)

16 - reboot with: reboot

EDIT: I had a problem with "A start Job is running" on startup. I solved this by deleting an old filesystem via Web-GUI of a USB-harddisk that I disconnected, and by commenting a line in /etc/fstab that was referring to a wrong swap-partition. Boot time is now 11 seconds.

Thanks a lot to ryecoaaron for writing this plugin.

Further information regarding the files the plugin is saving:

backup-omv-18-Jan-2019_14-12-01.blkid :: This is the output of blkid put in a file for informational purposes.
backup-omv-18-Jan-2019_14-12-01.fdisk :: This is the output of fdisk -l put in a file for informational purposes.
backup-omv-18-Jan-2019_14-12-01.fsa :: This is the fsarchiver file.
backup-omv-18-Jan-2019_14-12-01.grub :: This is the first 446 bytes of the disk where grub is installed
backup-omv-18-Jan-2019_14-12-01.grubparts :: This is the first 512 bytes of the disk where grub is installed and the partition table.
backup-omv-18-Jan-2019_14-12-01.packages :: This is the output of dpkg -l | grep openmediavault put in a file for informational purposes.

Display More

Is there a possibility to backup the system in a somehow easier way for restoring? Id like to just have an image of the system disk that I can burn on the new usb stick if the old one failed and have it just working from that... not possible?

I use dd to make an automated daily backup of the OMV system disk via a cron job. I've made more than 2,500 backups this way over the last seven years.

Quote from ryecoaaron

Sure, just dd a larger portion of the beginning of the disk. I think it is normally 2MB but I need to check.

Hey ryecoaaron, are you planning this change for fsarchiver as well?

Yesterday I had to restore my system running UEFI and was a nightmare. I lost 3 hours before I figured out the problem was the UEFI partition not being restored from .grubparts and then the actual GRUB/UEFI restore/install process to have the system back up and running again.

With the UEFI partition backed up would have been a breeze.

Quote from ryecoaaron

grubparts is only meant to restore grub and partition table info not partitions. The uefi partition is a full partition and would require a separate file (and restore) of its own. I guess I can look at backing that up too.

Allright, thanks for the clarification.

The UEFI partition is usually 512 MB but Debian/OMV only uses 136KB, so there is virtually no space and time required to back it up. It has a boot flag, so it should be easy for you to build a logic to detect it and back it up.

This would be a great addition, because means we could restore an entire OMV setup to a new disk with only few commands in systemrescuecd, and not to do other this like reinstalling OMV (to be honest I haven't thought about it).

Hey there, I just published a new guide (in the guide section), based on the OP.

I've rewritten it and updated it, describing the restore process.

I hope you appreciate it!

So, I had the pleasure of having to restore from a backup again after about half a year. I'm running into this issue though after trying to restore, I'll try running through all the things I've noticed.

Server refused to reboot, so loaded up my backup to a USB with SystemRescue. After booting into SystemRescue, tried loading the grubparts using dd, however I noticed that Gparted was still saying unallocated. I thought that was weird, so afterwards I tried reinstalling OMV5 instead. After doing that, I had my partitions, then tried doing dd again with grubparts. I noticed again the partitions switched to unallocated again.

Does that mean my backup grubparts are broken?

Next I tried a fresh re-install of OMV5 again. This time, no grubparts and only fsarchiver. After booting though, I ended up with a new error I've never seen: "grub disk get size" not found. I couldn't figure out after much Googling. Some suggest installing Debian first then using fsarchiver, but I'd rather try to fix this if I can.

I do know that my backup loaded successfully though. I loaded OMV5 onto another USB (fresh install) and used grub on the USB to load the OS on my main drive. Everything loaded and works. I tried update-grub command but when I reboot I still get the same error. Any idea why?

FIXED: After booting into the system, I had to install grub-pc and grub2 using apt install. Not sure why. Any reason why this would be the case? I don't remember randomly deleting it. It said that grub-legacy was installed - unless that's the normal operation.

hi, i'm tryng to restore a 160gb hdd to a 80gb omv 6 installation (7Gb of data) with backup from plugin.

the entire process vanished when restore the .grubparts ( the table parts is after the end of the disk)

is there any way to edit or resize the partitions

the system wont boot

thanks