[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Restore backup to KVM



	Hi.

On Fri, Sep 22, 2017 at 09:10:28PM +0200, solitone wrote:
> On 22/09/17 08:08, Reco wrote:
> > Execute this on your source system.
> > 
> > grep MODULES /etc/initramfs-tools/initramfs.conf
> > 
> > If it says MODULES=most then you're in luck as it means your initrd
> > contains all kernel modules for all kinds of hardware.
> > And restoring from backup into QEMU-KVM means you only need to
> > reconfigure the bootloader.
> > 
> > > Is there a way to configure KVM so that it resembles my bare
> > > metal, and the test is significant?
> > 
> > That's highly unlikely. On x86-64 there are two QEMU device models
> > worthy of speaking, and that's Intel i440FX and Intel Q35 motherboards.
> > Chances are you have different hardware.
> > 
> > So, it *will* have different NIC, Video adapter *and* most importantly,
> > IDE/SATA/SCSI controller.
> > 
> > Using Debian and MODULES=most you have a luxury of not to think about
> > it.
> 
> Ok, I see, and it seems I'm in luck:
>
> ~$ grep MODULES /etc/initramfs-tools/initramfs.conf
> # MODULES: [ most | netboot | dep | list ]
> MODULES=most

No wonder. This is Debian default, and Debian is famous for sane
defaults.


> But now I don't know what to do next, since:
> 
> > > I would install a basic debian system in KVM, and then overwrite it
> > > with my backed up files. Is this approach correct?
> > 
> > No. Some (but not all) configuration files would differ. Some (but not
> > all) packages would differ.

That depends on what kind of backup you have.

1) An old school case - you backup is made by dump(8).

Make yourself a file representing virtual machine disk.
Apply parted/fdisk/whatever to make appropriate number of partitions
inside it. Create filesystems.
Mount these somewhere, invoke restore(8) as needed.
Fix boot/grub/grub.cfg or whatever configuration file of bootloader
you're using.
Dismount filesystems, try to boot in QEMU.

2) Your backup is made by rsync(1) or tar(1).

Make yourself a file representing virtual machine disk.
Apply parted/fdisk/whatever to make appropriate number of partitions
inside it. Create filesystems.
Mount these somewhere, invoke rsync(1)/tar(1) as needed.
Fix extended file attributes, capability labels, SELinux labels if any
etc. By hand, that is.
Fix boot/grub/grub.cfg or whatever configuration file of bootloader
you're using.
Dismount filesystems, try to boot in QEMU.

3) You don't know what is used to make your backups, but it has an agent
(amanda, bacula, etc).

Grab yourself a liveCD, boot it in QEMU.
Invoke appropriate backup agent.
Reboot into (hopefully) restored QEMU disk.

4) You don't want to know how it's made but it's called Clonezilla.

Boot Clonezilla in QEMU. Invoke restore. Watch it done. Reboot.

5) It's all complex and confusing, the backup is done by dd'ing block
devices.

dd it back in QEMU disk file, try to boot. It may even work.

Reco


Reply to: