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

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

  • Correct, you only need to set


    • shared folder (where the backups are being saved)
    • method (dd, rsync or fsarchiver)
    • Keep (I set to "0" as I do not do regular backups and want to delete the obsolete backups by myself)


    DO NOT add enything to


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

    Just make a trial run to find out if there are any complications or not.


    Trial run: delete your system drive and restore from the backup

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



    Code
    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

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

    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?

    omv 5.5.23 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • The only way I can fix this is to not allow passwords with spaces. 5.1 is in the repo. This will not fix existing archives though.

    omv 5.5.23 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • 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

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

  • The dd grub restore isn't able to handle new drives.

    That really isn't the fault of the dd command. The grubparts file was always meant to restore to the same drive. Maybe you could restore it to the new drive and enter fdisk to very things then write the partition table again. Hard to say though.

    omv 5.5.23 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

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

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

    The non-ddfull options do not backup a large enough chunk for uefi or the RPi. I will have to look into that. I assume you are using a large OS disk and putting data on it and that is why you don't want to use dd full?

    omv 5.5.23 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!