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

Quote from macom

Just create a shared folder on one of the data drive and choose this shared folder in the GUI of the backup plugin as backup destination.

Make sure you are able to restore from the backup.

An alternative solution is to use Clonezilla to clone the complete system drive. This is done offline but easier to restore.

Line highlighted in red - I think I am overthinking it. I think I got it now. My confusion was in the wording . Please let me know if I got right:

1. SHARED FOLDER in settings means - the location where backup is saving to
2. There is no need to tell/point the plugin in the settings to the system drive since it is the purpose the plugin was made for.

Make sure you are able to restore from the backup - what could be the complications?

Thank you for clarification macom

Also question: what are the steps to restore the system with openmediavault-backup for the following scenario:

OMV version: 4.1.30-1

1. backup created with fsarchiver method
2. backup is on the USB drive
3. original system drive is removed from the machine and a new blank drive with the same capacity was installed to be used as a system drive

System restore steps:

1. Install fresh copy of OMV
a. Does the new copy of OMV must absolutely match the backup one? In our case - 4.1.30-1
2. Install and run System Rescue CD
3. Next Steps?

Thank you.

First of all, thank you @ryecoaaron for the backup plug in, and @bvrulez for the guide.

I had some problems restoring a fsarchived password encrypted .fsa file. I'm using OMV 5.2.1-1 Usul, 5.3.0-0.bpo.2-amd64 kernel, and v5.0 of backup plugin (fsarchiver version 0.8.5).

Using web gui backup plugin interface, a 6 chars password was defined (abcdef). Using a ssh session or a monitor connected to NAS (Thecus N5550), htop shows the command as:

fsarchiver savefs --cryptpass='abcdef' -o /srv/dev-disk-by-label-lixo/Images/omvbackup/backup-omv-28-Dec-2019_09-48-36.fsa /dev/sda2 /dev/sda1 -v -A

When trying to check .fsa backup file, -c (or --cryptpass=) option is used, with various degrees of success. What does NOT work:

root@omv-1:/srv/dev-disk-by-label-lixo/Images/omvbackup# fsarchiver --cryptpass='abcdef' archinfo backup-omv-28-Dec-2019_09-48-36.fsaoper_restore.c#1166,extractar_read_mainhead(): you have to provide the password which was used to create archive, cannot decrypt the test buffer.root@omv-1:/srv/dev-disk-by-label-lixo/Images/omvbackup# fsarchiver --cryptpass=abcdef archinfo backup-omv-28-Dec-2019_09-48-36.fsaoper_restore.c#1166,extractar_read_mainhead(): you have to provide the password which was used to create archive, cannot decrypt the test buffer.root@omv-1:/srv/dev-disk-by-label-lixo/Images/omvbackup# fsarchiver -c abcdef archinfo backup-omv-28-Dec-2019_09-48-36.fsaoper_restore.c#1166,extractar_read_mainhead(): you have to provide the password which was used to create archive, cannot decrypt the test buffer.root@omv-1:/srv/dev-disk-by-label-lixo/Images/omvbackup# fsarchiver -c 'abcdef' archinfo backup-omv-28-Dec-2019_09-48-36.fsaoper_restore.c#1166,extractar_read_mainhead(): you have to provide the password which was used to create archive, cannot decrypt the test buffer.root@omv-1:/srv/dev-disk-by-label-lixo/Images/omvbackup# fsarchiver -c - archinfo backup-omv-28-Dec-2019_09-48-36.fsaEnter password: oper_restore.c#1166,extractar_read_mainhead(): you have to provide the password which was used to create archive, cannot decrypt the test buffer.

The only format where the password is accepted obliges escaping the single quotes used on the archiving command, and only using -c (not --cryptpass) option format:
root@omv-1:/srv/dev-disk-by-label-lixo/Images/omvbackup# fsarchiver -c \'abcdef\' archinfo backup-omv-28-Dec-2019_09-48-36.fsa====================== archive information ======================Archive type: filesystemsFilesystems count: 2Archive id: 5e057ad3Archive file format: FsArCh_002Archive created with: 0.8.5Archive creation date: 2019-12-28_09-48-46Archive label: <none>Minimum fsarchiver version: 0.6.4.0Compression level: 8 (zstd level 8)Encryption algorithm: blowfish

===================== filesystem information ====================Filesystem id in archive: 0Filesystem format: ext4Filesystem label: Filesystem uuid: 015cdc11-579c-4424-98fb-16ba5978c3c5Original device: /dev/sdb2Original filesystem size: 10.23 GB (10987560960 bytes)Space used in filesystem: 3.13 GB (3357065216 bytes)

===================== filesystem information ====================Filesystem id in archive: 1Filesystem format: vfatFilesystem label: NO NAME Filesystem uuid: <none>Original device: /dev/sdb1Original filesystem size: 510.98 MB (535805952 bytes)Space used in filesystem: 140.00 KB (143360 bytes)

I've made a test, by modifying the plugin code, changing the line
password="--cryptpass='${passwd}' "
to
password="--cryptpass=${passwd} "

and that allows for a the password to be correctly recognized both using -c password, --cryptpass=password and -c - (and typing the password), during a restore or a backup file check (using archinfo command).

I'll leave it to you to decide if this is modification that would bring benefits to the mainstream plugin code. I'll leave my script permanently like this, since it makes it possible to easily restore OMV.

Best regards.

Mauricio
São Paulo - Brazil

Quote from macom

1a - no
3 - mount the drive with the backup

Thanks macom, I will give it a try this weekend.

@mauricio.mirabetti and @ryecoaaron thank you very very much guys.
You actually saved my life
I got my restore working with setting the password like @mauricio.mirabetti suggested.
Example:

fsarchiver -c \'mycoolpassword\' archinfo /destination/to/mybackup.fsa

I think that that is still a good solution.
Thanks!

Quote from ryecoaaron

I will have to investigate when I get a chance but your change would break things if the password had a space or $ or ; or | in it. The output gives me the impression that archive created by the pluing has the single quotes as part of the password. Not sure why. I assume specifying -c - so that you are prompted for the password also does not work with abcdef? And are you literally testing this with abcdef for the password?

Answering your question about -c -, it does not work even including " ' " when typing. The only working format is escaping single quotes, and only using -c option, not --cryptpass.

I agree with you that, for some reason, the single quotes are being considered as part of the password, when it shouldn't. At the same time, one important information: I tested all these command alternatives directly on the tty terminal (vga + keyboard, directly on the NAS): it turns out the single quotes are never considered as part of password, meaning one's able to restore/check .fsa just by typing, in this example, abcdef either on -c abcdef, --cryptpass=abcdef, --cryptpass='abcdef', and typing it with -c -. Makes me think it might be related to the shell. Script shebang line looks ok, and bash has no reason to pass on the single quotes to the fsaarchiver executable.

Really odd. But your solution might give us some time to investigate further, while being able to benefit from live / mounted partitions backup, allowed by fsarchiver. Thanks for that.

Mauricio

Quote from macom

1a - no
3 - mount the drive with the backup

I tried but it doesn't work. It does restore to a point where it boots to emergency mode and recognizes my root password from backup but thats it. I have attached the log of what I have done/steps.omv restore.txt

Hey Guys, after playing around with fsarchiver I decided to put back the original ssd and it won't boot now.

So what what was done was:

1. installed OMV 4.x
2. installed extras, etc.
3. created a backup with backup plugin using fsarchiver method
4. removed ssd and put it away
5. installed a different hdd and installed a fresh copy of OMV 4.x on it
6. tried systemrescuecd to restore to it from the backup, basically used that hdd with the OMV on it as a guinea pig for all sorts of backup testing
7. removed the hdd and installed ssd(the one I removed in step 4)
8. booted the system and got a message - "REBOOT AND SELECT PROPER BOOT DEVICE OR SELECT BOOT MEDIA..."
9. booted from systemrescuecd and checked with fdisk -l all the devices were there - sda1,2,3

Qeustions:

1. what could have possibly gone wrong and at what point?
2. did the original backup with fsarchiver corrupted the file system?
3. could UEFI settings get changed? I remember during OMV install the installer asked something about boot and UEFI was mentioned.

Can anybody elaborate on this?

Thank you

Thanks bvrulez for the handy restore tutorial.

The drive in my OMV server died and I replaced it with a different make & capacity drive. The dd grub restore recreated the old drive's partition tables (didn't expand to the larger drive's size) which was ok with me. However when booting it returned "Invalid partition". I tried the steps 3-4 times with variations in the destination device naming. This is what I believe to be correct after re-reading numerous materials --

dd if=backup.grubparts of=/dev/sda

followed by

fsarchiver restfs backup.fsa id=0,dest=/dev/sda1.

But it still wouldn't boot. I also tried grub-install to manually reinstall grub. It was never able to boot.

Eventually I re-installed OMV from scratch, then booted from the USB SystemRescueCD and used fsarchiver to restore the system files. That initially seemed like the longer route, but it ended up being much easier and ultimately the only path that worked for migrating to a new drive. The dd grub restore isn't able to handle new drives.

Quote from chefp

I tried the steps 3-4 times with variations in the destination device naming. This is what I believe to be correct after re-reading numerous materials --

dd if=backup.grubparts of=/dev/sda

followed by

fsarchiver restfs backup.fsa id=0,dest=/dev/sda1.

But it still wouldn't boot. I also tried grub-install to manually reinstall grub. It was never able to boot.

Eventually I re-installed OMV from scratch, then booted from the USB SystemRescueCD and used fsarchiver to restore the system files. That initially seemed like the longer route, but it ended up being much easier and ultimately the only path that worked for migrating to a new drive. The dd grub restore isn't able to handle new drives.

Display More

I confirm such behavior of the restore process as well. I wasn't be able to boot even after successful grub installation and update all entries. dd of .grubparts does not create correct partitioning. Maybe it is because my installation was done on an UEFI machine. Manual partitioning of the system disk did not help with the issue, only preinstallation of the OMV without its configuring followed by "fsarchiver restfs..." command leaded to a working system on a new drive.

ryecoaaron do you have any suggestion or advice how to make migration process easier without the need to dd full disk?