Pinned Backup a live system

    • sparx wrote:

      gparted-live-0.29.0-1-amd64.iso
      That is definitely new enough. Was the drive previously part of a zfs pool and maybe the signature was wiped? If you can't resize, you could create/format the partitions on the new drive and rsync the data to it. You would just need to boot a debian image (or something else) in repair mode to fix/install grub.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      That is definitely new enough. Was the drive previously part of a zfs pool and maybe the signature was wiped? If you can't resize, you could create/format the partitions on the new drive and rsync the data to it. You would just need to boot a debian image (or something else) in repair mode to fix/install grub.
      Quite possibly. I was running freenas for a short while. Cant really remember what disk i was using. Ill keep running the disk for now. Wanted to save some watts. But the difference is rather small any way.
    • molnart wrote:

      did anybody try migrating the omv root filesystem to btrfs and do backups using snapshots? i think this would a much more elegant solution
      @subzero79 uses btrfs snapshots (or did at one time). And of course it is more elegant but that isn't what the majority of OMV installs are using (since the ISO uses ext4) and I'm not going to try a noob how to convert their os drive to btrfs. I am current working on a couple things that might make it easier.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      that isn't what the majority of OMV installs are using (since the ISO uses ext4)
      well btrfs for system partition could be a route to go down for future releases, at least as an option (i do not like how the current installer overwrites the whole system partition quite agressively. an advanced mode with own partitions setup would be welcome)
      HP N40L, 4 GB ECC RAM, 3x WD RED 3TB + OCZ Vertex3 128 GB SSD
    • molnart wrote:

      well btrfs for system partition could be a route to go down for future releases
      I filed a bug/feature request for this almost two years ago (lvm was primary idea but btrfs was mentioned in comments).

      molnart wrote:

      i do not like how the current installer overwrites the whole system partition quite agressively
      That is done to somewhat prevent people from putting data on the OS drive (major idea of OMV).

      molnart wrote:

      an advanced mode with own partitions setup would be welcome
      There is an advanced mode... It is called "install debian first using debian ISO then install OMV". If you are an advanced user, this is not a problem at all.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • molnart wrote:

      well btrfs for system partition could be a route to go down for future releases
      Actually it's implemented like this on all the ARM OMV images today (the one for Raspberries not included, there it's still ext4 and I have no motivation to change this). But just like on x64 also only 'advanced users' can make use of since they have to become familiar with the snapshot concept, how to backup what and how to adjust fstab to get back to a former snapshot first (just as a reference for users stumbling across this: forum.armbian.com/index.php?/t…findComment&comment=17427 but only the fstab stuff is relevant any more since all the other modifications are part of the base OMV/Armbian image already)
    • You can download a live Clonezilla and burn it to a flash drive.
      Then clone the drive by using the 'save image' option.
      Choose Expert mode....

      There is an option for you to fix bad sectors before cloning it: "Check and Repair System..."

      If you have issue after restored the image, then run a 'fsck' to fix bad sectors.
      OMV v4.0
      Asus Z97-A/3.1; i3-4370
      32GB RAM Corsair Vengeance Pro
      4x3TB RAID10
    • fpabernard wrote:

      The backup plugin has a nice integration with clonezilla and it works fine. It's not a live backup as you have to boot on clonezilla (from the WebGUI !) but in return using clonezilla for restore is very safe and easy
      Is it true that in 2014 the plugin had integration with Clonezilla, but not any longer?
      I made a backup with the plugin but don't find an option to boot into Clonezilla to restore.
      Is it actually possible to restore these backups with Clonezilla?
      Because people seem to suggest to use Clonezilla to create the backup, but then I'd have to shutdown the system every time I make a backup.

      My plan is to make backups of a running system every time before I change system settings in OMV, so I can restore if I mess up.

      ryecoaaron wrote:

      molnart wrote:

      did anybody try migrating the omv root filesystem to btrfs and do backups using snapshots? i think this would a much more elegant solution
      @subzero79 uses btrfs snapshots (or did at one time). And of course it is more elegant but that isn't what the majority of OMV installs are using (since the ISO uses ext4) and I'm not going to try a noob how to convert their os drive to btrfs. I am current working on a couple things that might make it easier.
      What is it you're working on to make things easier? :)
    • Jip wrote:

      Is it true that in 2014 the plugin had integration with Clonezilla, but not any longer?
      The plugin had an option to install and boot from the clonezilla ISO but the backup the plugin performed had nothing to do with clonezilla.

      Jip wrote:

      I made a backup with the plugin but don't find an option to boot into Clonezilla to restore.
      The plugin just rsyncs the system files to a directory. Clonezilla can't restore that.

      Jip wrote:

      Is it actually possible to restore these backups with Clonezilla?
      Nope.

      Jip wrote:

      Because people seem to suggest to use Clonezilla to create the backup, but then I'd have to shutdown the system every time I make a backup.
      Yep, backing up your system when it is not running is the best way to backup.

      Jip wrote:

      My plan is to make backups of a running system every time before I change system settings in OMV, so I can restore if I mess up.
      Seems a bit excessive. Why not set up a virtual machine to practice before making the change to the actual system? If it is a large change that didn't go perfect every time in the virtual machine then make a backup.

      Jip wrote:

      What is it you're working on to make things easier?
      Nothing I want to mention right now.
      omv 4.1.14 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Thanks for clearing that up!

      Yes it feels excessive when I have to shutdown and use Clonezilla every time I make changes to the system settings.

      I'm looking into Relax-and-Recover right now and I'm considering BTRFS snapshots. I'm using it on another system already but haven't rolled back a system with them. So I'd have to figure that out.

      I'd like to secure myself from messing up my system without keeping a separate VM installation that matches my OMV installation to try everything out beforehand. For big changes I'll be using a VM, but it's the small changes causing unexpected problems I'm trying to avoid. Or just plain user error.
    • I run automated dd backups of my 16GB SSD OMV system drive on cron daily at 7:00am. I keep a week's worth, and the oldest one is automatically deleted right after the daily image is made.

      About every other month I restore the most recent daily backup image to a spare identical 16GB SSD and boot the machine with that restored image. I keep an eye on it during the day, and I have never seen any type of problem running that restored dd image copy. In fact, I just keep running that copy going forward and return the disk that was the source of the dd image to the drawer that has a few more identical spares in it.

      Being only 16B, these images take only eight minutes to create, but almost twice that to restore. So, depending on how large your system drive is, this method may or may not be practical for you to protect you from making a bad change to your system.

      But I can very easily get out of a total screw-up that toasted my OMV system drive. Compare that to a reinstall and complete configuration from scratch.

      Finally, there those out there who will say that this practice is unreliable and improper. But I am here to tell you that it has never failed me and it has saved my bacon several times over the years.

      Regardless of what you wind up doing, make sure that the backup, when restored is bootable and fully complete.

      And make sure you test the entire process end to end. It's not a backup until you prove to yourself that it's actually fully restorable and boots back into a running OMV. My dd images are.
      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • Hi all

      My system crashed a few days ago, use a HP Gen8 Micro. I used to have a 3.5 disk attached to the internal USB port and 4 HDD data disks.
      The system disk crashed a few days ago, and I decided it was time to replace it with a more proper setup, so got a SSD and attached that to the ODD BAY (only other way to use the swap bays for data disks)

      The thing is that I've lost absolutely no data, but I had a few docker configs on the old omv and I thought it would be nice if I could get them back without reinstalling. I also had the Backup plugin installed and I ran the backup quite frequently.

      Not a linux pro, but I understand basic parts, so I read the thread about the plugin and just want to clarify;

      To restore the system, using the rsync backup, is the the procedure to follow still the one in the first post? And that works even though I installed a new system disk?

      Basically I should reinstall omv on the new system disk and then follow the procedure? (Just rsync the backup won't work, gets a grub error about non system disk)
    • Users Online 1

      1 Guest