On 13-10-17 09:42 PM, Jim Klimov wrote:
On 2013-10-17 23:35, Geoff Nordli wrote:
I use the built in vbox initiator.
Not the highest performing setup, but these are small business services
and disk IO isn't the biggest issue we have.
I am using it for automated backup system. I virtualize their servers
into vbox, pause the VM(s), zfs snapshot, send to a different pool and
send another copy offsite.
In such case note that the recent versions (circa one year now) of the
script support creation of automatic ZFS snapshots of the backend
storage after VM stop and before VM start, and at least for file-based
VMs (including over NFS) and for local zvols it should be able to
detect the list of involved ZFS datasets, as well as you can provide
a list of other datasets you know as related (i.e. iSCSI LUN zvols).
I did not have a scenario exactly like yours, but it may be possible
(either out of the box or after minor scripting) to use the shutdown
action to pause and un-pause the VMs and have this action wrap the
creation of the snapshots. Certainly (right now) you can use the
"vbox.sh zfssnap" method between your own pause/unpause calls with
just one generic command to call from your automation scripts.
I am not sure if pause/unpause provide for very good backups, since
they would seem like a reset upon recovery (unlike savestate/restore,
but at the cost of some more downtime).
Feel free to ask for more features, I might get around to implementing
them one day... or send patches :)
The vboxmanage pause works great with vbox, because it just pauses all
activity and it doesn't drop connections to anything that is going on.
It also flushes the disk buffers and it only takes a few seconds for
this to happen.
With the script I have, it does backups in batches, so it will pause all
of the VMs in the batch, then does the snapshot, then resumes all of the
VMs, which guarantees that everything is at the exactly same point.
Couple feature requests. If we had volumes linked to a controller/port,
then if it could automatically create the iscsi target and check to make
sure that it is attached to the VM, that would be awesome.
Related to that, if you had the option to control flushing. Any
production system should not have flushing enabled.
http://www.virtualbox.org/manual/ch12.html#idp56076560
To enable flushing for SATA disks, issue the following command:
VBoxManage setextradata "VM name"
"VBoxInternal/Devices/ahci/0/LUN#[x]/Config/IgnoreFlush" 0
I don't know if something like this would go in the vboxsvc, but there
are three different things that happen with my backups: 1) snapshots 2)
replication 3) purging/retention.
1) when I snapshot, it reads a config file, which allows you to have
multiple "targets" to send the snapshot to. I create a touch file in a
directory structure that the replication script reads, after successful
replication it deletes the touch file.
2) replication looks at the targets that were created when the snapshot
happened. I normally run the replication at night.
3) retention cleans up snapshots (when you run a snapshot you set
retention policies).
my scripts are a spaghetti mess though :)
have a great day!
Geoff
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
