Beiträge von rumipuffs

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.

Zitat von raketenraupe

Just wanted to say thanks for the guide.

Had some SMART errors on my system ssd and before replacing it, I did a fsarchiver backup of my system ssd with the backup plugin. After replacing the ssd I tried restoring without installing OMV to the new ssd first, so on a blank unformatted disk. But that didn't work for me. Couldn't get it to boot.

So i installed OMV5 fresh from USB on the ssd and afterwards booted systemrescue and did the fsarchiver restore on the ext4 partition. Everything worked from there on and all settings / docker containers were restored. Only had to edit /etc/fstab because the old uuid of the swap partition was in there from the restore I guess. But no big issues.

Thanks for the plugin and the short guide!

Alles anzeigen

Curious, exactly how did you edit the fstab? Like, after accessing systemrescue, log back in to OMV in CLI and use nano to edit fstab. Do you simple delete the swap UUID? If you need to put in the old one, where do you get the old UUID from?

So turns out the -o option is in the script. But, it isn't available to change on the GUI. I've added it myself and it seems to work.

Need to add SCRUB_OLDER_THAN_DAYS='numberOfDays' to /etc/snapraid-diff.conf

Just can't hit the "save" button in the future otherwise it'll wipe it out.

Zitat von gderf

The built in scripts does what you have listed in 1-4.

But it does not do -o. If you want that use another script that does that. There are several out there, just google search for "snapraid helper" and see what each is capable of.

Thanks. Does that mean "Scrub Frequency" literally means, only do scrub x number of days? I'm guessing if it does it records when was last scrub date?

I've tried searching for the answer to this but still unsure.

I've finished setting up my drives, parity, etc. I've completed my first sync with all my existing data. Now, I'm trying to understand the first page of options (Settings tab).

After hitting the "Scheduled Diff" it creates a "Daily" cronjob which I assume runs a bash script and uses the settings I've set below under "Diff script settings".

From my understand after reading the Snapraid Manual, diff, scrub, and sync are all different commands. What I'm wondering is if, the default script built-in to the plugin is doing all three of these. If I'm reading all the hottips correctly, it makes me believe that it does the following:

1. Run diff command;
2. If deleted and updated files do not meet threshold run sync;
3. If sync is successful run scrub;
4. Scrub only as much percentage as prescribed in settings;

Tell me if I have it right or it doesn't do this at all. What I'd like to have is automated scrubs which I'd like to set to something like 3-5 percent daily. What seems to be missing in settings is the -o setting for don't scrub data that's been scrubbed before in the last x days (unless that's the frequency setting).

If the right answer is, do it all manually, that's okay too.

Zitat von macom

What is the output of

fsarchiver archinfo <name of archive.fsa>

That will tell you what is in the archive (how many partitions, which filesystem, which size etc.)

Have you seen this (first post is a how-to):

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

Alles anzeigen

Thank you for that link! Bookmarked. It pretty much answered my question. Looks like I need to dd the .grubparts first, then I should be able to restore as normal.

I'm hoping someone can help me here. I've tried reading through all the documentation and tips here but still a bit confused on how fsarchiver works with restoring.

What I want to do is clone my drive using the fsarchiver backup I've created. My current drive is spitting out a lot of errors and I don't want to continue using it. I have the .fsa file ready to go, but going through the documentation and checking the file, it seems to only include the 1 partition sda1 and not the other 2 I see which include the swap partition. This leads me to believe I won't be getting an exact one-to-one match if I only restore the omv fsarchiver backup.

I'm thinking, do I need to install OMV on my new SSD first (to get all the right partitions setup)? Then restore only the systems partition using the .fsa file I have (using the instructions on the first page)? Just wondering if in the future, if the main drive ever dies and I only have access to .fsa files, is this the best way to do it?