Correct restoration directions to restore a dd backup

Wow, this is a lot harder then I think it should be... Please understand, I come from a windows world, where even the linux backup and restore programs I use (Such as acronis true image, and disk director) just work. Restore to smaller drive? No problem I will take care of that for you. Restore to larger drive? Sure, how did you want to do it?

I have booted into a live version of Lubuntu, as I am trying to do this on a different system, with a different sized (Smaller) drive. Original drive (I think) 240 GB, this one 120 GB) (Don't worry, the entire backup will fit on the new drive almost 20 times.. There is enough room)

I started with gunzip -c backupfile.dd.gz | dd of=/dev/sda status=progress

It went through the whole process, writing 111 GB of a 7 GB file (That made no sense to me), and I was greeted with a blank drive.

I then found some other directions that suggested I should restore the partition table first using the grubparts file (Can't seem to find those directions again.) but it seemed to kind of work.. Except I ended up with a 222gb partition on a 120 GB drive. That obviously would have been bad.

So now I am kind of at a total loss here. How do I do this, what should be a very simple task?

A lot of that makes good sense. Thank you for taking the time to explain it. I personally have had issues with clonezilla restoring to a smaller drive, but it may be just the world of GUI and things just working. But that was for something else entirely. And I know that gz is a compressed file format, its just, again, from the world of Windows, when you have a 7 GB file, that is a compressed disk image that contains 27 GB of data and you restore it, it only every writes 27 GB. DD wrote the whole disk (It wrote 111 GB on the 120 GB disk, and 222 on the 240 GB disk) And please don't think I am complaining about this. Things work differently under Linux, I understand that, and I am sure there are reasons for it. I only mention this so readers can understand why I am so confused about all this.

So we are still at the point where I have restored, both to a smaller drive, and to the same size drive, and in moth cases I get a black screen, white writing that says:

"GRUB"

with a flashing curser.

From my understanding when grub fails and drops to a prompt I should get "GRUB >" but I do not, I seem to be missing the >, and all ability to type. Nothing works. No keypresses, enter, Crtl-C, Crtrl-Alt-Del, nothing. It was left on for 16+ hours to see if it would do something when I went home for the evening, but it is still there, so there must be something wrong with either the restore, or something else.

The only thing of note is that I am trying to boot it on a different machine with only the system disk installed. In my limited experience with Linux, that should not matter. I have always been able to swap around system disks between machines and Linux just dealt with it. I am using the 240 GB disk at this point to eliminate the size difference being the problem. Restored system disk is the same size as the original.

So any idea why I am not able to get it to boot?

Can you provide just a bit more information on the "Rescue option." Is this an option I am given on install (Like in a windows install, "Repair your computer") Or is this a command I use from the command line. A GUI program I use when booting into a live desktop?

And as far as Linux doesn't do many things like windows, I agree. Under most circumstances Linux does stuff better, I agree. I even tried to switch to Linux for my daily driver, but unfortunately it doesn't play well with many of my devices.

Well, I found the "Rescue Mode" but it doesn't seem like its going to help me.. Or I don't know how to use this (I am SOOO glad I am doing this this way now rather then an actual emergency. I would be in such a bad place..( Anyway)

The rescue was saying it couldnt' mount the filesystem on the device, so I decided to boot into a live linux again to try and browse the drive I recovered the backup to, and it is telling me there is an error mounting it because it "can't read superblock on /dev/sda1"

Now what?

**EDIT**

So I decided to try to restore again, as I figured there was no reason not to. And I am getting the same error whenever I try and read anything off the drive. So I assume either I am doing the restore wrong, or something else is wrong somewhere.

Quote from ryecoaaron

Are you still trying to restore the larger backup to a smaller drive? You can't do that with a dd image.

No, to try and avoid as many issues as I can, I have restored it to a drive of the same size. Original is a 240 GB Kingston SSD, this is a 240 GB SSD of a different make, but 240 still the same.

I will add something else, that may be helpful, or not. I do get these constant errors, and quite often on reboot I am forst to do a Fsck (Or whatever it is that si close to that) You told me in a post many months ago not to worry about it however.

In addition, pretty much any changes to the system (Apply configuration) take forever. Yesterday I stopped looking after about 60 min,.

Hence why I am trying to restore a DD.

So please may I ask for some help on the error I mentioned above, where after a restore (On the same sized drive) Debian rescue reports it is unable to mount the filesystem, and in a live linux I get "can't read superblock on /dev/sda1"

Ideally I would like to get this resolved before a full drive failure. As of right now I am apply any configuration changes. Applying the changes results in "Please wait, the configuration changes are being applied." I wanted overnight, and when I came back, the "working" page disappeared, changes had not been applied, and I was told I needed to apply changes.

Quote from ryecoaaron

it isn't restoring properly. Hard to say why.

Use omv-regen to make a backup now and reinstall/restore to new drive following the omv-regen docs.

I was going to ask about that (finding a way to backup the config and re-installing), as it would also permit me to move to OMV 7. The biggest issue I have is making sure my docker containers are properly backed up/restored. Although most can just be re-created from scratch, Seafile and the containers associated with it would be quite bad if they didn't backup/restore properly.

Quote from jata1

and my 2 cents...

If you are trying to restore an image that 'might' have some file corruption then you could end up with a bad system even if you do manage to restore the dd backup.

omv-regen is a good choice especially if you have a load of config in omv that you will take you a load of time to recreate. I have used omv-regen but I usually start with a clean install and manually set everything up again. I have quite a bit of config in my setup and I can get the everything back up and running in about 1 hour. omv-regen will only recreate core omv stuff and so some manual (cli) config will not get restored.

For the manual approach, take screen shots from OMV GUI for things like shared folders, rsync tasks etc to make it easier to setup.

Also you are using a very large drive for omv install. Is this because you are using the disk for other stuff (docker install / container etc)? If so you might want to consider using separate disks. omv works well when installed on USB thumb drive (with flash memory plugin to minimise wear). Then use your new SSD for everything else for the system setup.

What I do and it makes backup / restore much easier is this:

1. omv os/install disk - On a small ssd or usb flash - use it for nothing else

2. omv-system disk - Decent size (240gb is fine) for all system services and data (VMs, docker, containers, config data for containers etc..)

3. omv-data disk(s) - For file / media storage

Honestly, once you have your setup like this (or similar) you will be a happy camper

Display More

I have thought about installing it on a USB, but I have the SSD's laying around, I don't have any open bays for SSD's to run the docker containers on, they get backed up with the daily backup and running the docker containers on a drive other than the system disk, although I am sure would be easy to obtain, is a skill I don't posses.

But thank you for the suggestion. It is often good to consider other solutions to your issues; in this case however I have considered it and unless there is something I am missing, isn't the best solution for me personally.

Quote from jata1

if you use omv-regen, you need everything fully up to date on OMV7 on the source (incl any plugins). Both source and dest need to be same omv version.

Also I understand that you want to use the new SSD for both OS and docker etc. This is also a totally fine approach.

If it was me doing this, I would start with a new clean omv install (manual setup) on the new SSD. Get OMV setup with docker and plugins you need. Copy the data you need across from the old SSD (such as docker container config (volumes). Create the shared folders. Then use compose to recreate your containers pointing the volumes to the data on the new SSD.

This way you will have a totally new/clean system and all will be good (hopefully).

Display More

That sounds like perhaps the best approach, as I don't know if OMV 6 is totally up to date, and updating it likely won't happen with these errors.

Most of my containers do not have volumes of their own, pretty much 90% of my containers use bound directories instead of volumes, so unless I totally misunderstand how docker works all I should need to do is create the containers again pointing them to the same directories, and they should just keep working. If there are no actual volumes for the docker container, there is nothing to backup/restore, is that in fact correct?

For example, my qbittorrent has the "\config" dir bound to "/SixTBpool/Config1/qbittorrent" whereas SixTBpool is a zfs filesystem on separate mechanical drives I will just re-mount under the remake of OMV. So when I recreate the container, I again bind the config directory to "/SixTBpool/Config1/qbittorrent" (Assuming the mount point is the same) and it just picks up where it left off?

Quote from ryecoaaron

it isn't restoring properly. Hard to say why.

Use omv-regen to make a backup now and reinstall/restore to new drive following the omv-regen docs.

Seems as though omv-regen will not work either:

Hit:9 http://download.proxmox.com/debian/pve bullseye InRelease
Get:10 https://openmediavault.github.io/packages shaitan InRelease [12.8 kB]
Get:11 https://openmediavault-plugin-developers.github.io/packages/debian shaitan InRelease [3934 B]
Hit:12 https://download.docker.com/linux/debian bullseye InRelease
Hit:13 http://packages.openmediavault.org/public shaitan InRelease
Fetched 16.7 kB in 2s (10.8 kB/s)
Reading package lists...
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 157129 (apt-get)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

Failed updating system. Exiting...
root@omvhp:~#

Tried more then once.

Ideas?