[clug] Seeking FOSS Hypervisor and Management GUI

[Bob Edwards]

On 01/10/14 15:16, George at Clug wrote:
>      Bob,
>
> 1) Do you know how a Linux server can prepare for UPS shutdown by
> stopping services and then changing the mount of the root partition to
> be read only ?  This is something I have yet to find the time to
> investigate but understand what should be implemented by the UPS
> shutdown process.
>

Nope. But I'm sure it can be done...

>
> 2) With regards to your statement "I was thinking of just
> backing-up/copying the system area";
>
> With MS Windows, I would never have tried to backup just Windows
> System area and hope to get the server to ever reboot again, however I
> understand that this is actually possible with Linux (not that I yet
> know how).
>
> What would need to be backed up (not including /home if this is where
> the data is), and can it be restored to a live system?  (I guess this
> is documented somewhere in the Internet)
> (my quick suggestion of what would need to be backed up  for MySQL,
> DoveCot, Postfix, Samba?).
> /etc
> /var/
> /bin
> /sbin
> /selinux
> /proc
> /lib
> /lib64
>
> Does the broken server's drive need to be mounted in another server
> and then the files restored across the existing, broken server? Or if
> the server is actually running, can services be stopped and the files
> be restored.
>

So, without wanting to teach you how to suck eggs, when I install
a system (VM or otherwise), I invariably (ie. always) put /home on
a separate block device (partition, LVM volume, device, etc.) from /.
In some cases /home is NFS mounted, or bind mounted inside a container.

I sometimes put /var on it's own device as well.

So, I was assuming you would have done likewise...

With everything except /home on a single device, it is easy enough
to do what I suggested in a previous post - back up the entire root
block device ("system area") as one image for testing/experimental
purposes. Not sure I would recommend restoring it on a "live" system,
but certainly you can restore when the VM is down and then start the
VM up again with the good image.

In terms of normal backups, I backup /etc (also managed with
etckeeper...), /home, /root, /usr/local and /var.

No point in backing up /proc - it is entirely dynamic. Similarly for
/dev if your distro is using udev.

If I need to rebuild, then I rebuild from scratch. Slower, but quite
rarely required. The backups of /etc and /var have all the system
settings etc., including SSH keys, passwords, packages that were
installed etc.

/bin, /sbin, /lib, /lib64 and /usr are all strictly from the distro
(usually Debian, but sometimes Ubuntu, LinuxMint, Kali etc.), so
little point in backing them up, except when experimenting.

Having said that, for my various Linux Containers, I regularly copy
each entire container from one host to another so that they are ready
to be brought up on the "other" host if their primary goes down (again,
rarely happens).

Anyway, what you are doing with VM snapshots sounds interesting - keep
us in the loop.

Bob Edwards.

>
>
> At Wednesday, 01-10-2014 on 14:32 Bob Edwards wrote:
>
>
> On 01/10/14 13:32, George at Clug wrote:
>>        I really hate showing my ignorance, I had to look up what
> dd was;
>> The dd command copies a file, converting [1] the format of the data
> in
>> the process, according to the operands [2] specified.
>>
>> Snapshots have an advantage over "copies" of a virtual machine,
>> especially when that virtual machine is a data repository that is
>> larger than the free space (even when compressed) on the host
>> hypervisor. And 6TB of data takes a while to copy, dd, etc.  A
>> snapshot should just fork any new changes to the original image for
>> the life of the snapshot, consolidation is the process of merging
> the
>> snapshot changes back into the original image.  If the snapshot is
>> not too old, both of these tasks are usually are very quick.  At
>> least that is how I understand the VM snapshot process.
>>
>
> That's all true.
>
> I was thinking of just backing-up/copying the system area, not the
> entire data repository, which should be backed up elsewhere. I suppose
> the updates you want to apply might break the data repository, in
> which case you could restore it from backup. But that would take
> very many hours...
>
> Cheers,
>
> Bob Edwards.
>
>> http://www.computerhope.com/unix/dd.htm
>>
>>
>> Create a ISO disc image [3] from the CD in the computer.
>>
>>
>> dd if=/dev/sr0 of=/home/hope/exampleCD.iso bs=2048 conv=noerror,sync
>>
>> To be honest most of my VMs range from 500GB to 3TB, but could grow
> to
>> 9TB quite easily, so I like to have a solution that can support into
>> the future.
>>
>> Thank you for your comments. An old saying that I rather like is
>> "_there is more than one way to skin a cat_", even if I am a cat
> lover
>> who believes the best way is "not to skin a cat at all".
>>
>>
>>
>>
>>
>>     Of course, "snapshots", as you are wanting to use them, are just
> a
>> "convenience".
>>
>> You can almost as easily just shutdown your VM when it is good, run
> dd
>> etc. into gzip to get a copy of the VM disk image, then start it
> back
>> up and go ahead and break it.
>>
>> When you want the original back, just gunzip and dd the saved image
>> back over the broken VM filesystem and you effectively have the same
>> result as a snapshot...
>>
>> Do it again and again, until you get bored...
>>
>> Script it all up, for more convenience...
>>
>> Cheers,
>>
>> Bob Edwards.
>> ttps://lists.samba.org/mailman/listinfo/linux [4]
>>
>>
>>
>> Links:
>> ------
>> [1] http://www.computerhope.com/jargon/c/conversi.htm
>> [2] http://www.computerhope.com/jargon/o/operand.htm
>> [3] http://www.computerhope.com/jargon/i/isoimage.htm
>> [4] https://lists.samba.org/mailman/listinfo/linux
>>
>