[colug-432] What's the best way to back up a remote VPS?

[R P Herrold]

On Mon, 17 Jun 2013, Rob Stampfli wrote:

> It's becoming harder and harder to find a reasonably priced VPS
> that has built-in backup/restore capabilities, but cheap, unadorned
> VPS providers abound.  So, I've been wondering how does one go about
> rolling his own backup, i.e., backing up the file system on a VPS so
> that, if the VPS does somehow get clobbered, there is a straightforward
> and relatively quick path to reincarnate it again

There are lots of models for non local, perhaps virtual 
machines and their administration.  Many models assume that 
there is a gold master (either produced by the vendor, by a 
third creator, or for local deployment), and then populated in 
the config files by cfengine / puppet / ansible, ... choose 
your flavor.  Part of the underlying assumption is that these 
are 'spot instances', and of short life, and the pricing 
(cough, AWS) reflects some premium to incentivize turning off 
idle machines and releasing the image resources.  The 
assumption is that there is no unique state on that instance 
than cannot be replicated by pushing some database keying onto 
a fresh instance, and that there is a durable backing store 
database to query.  So: a MVC model


Other models are for long running instances, essentially 
'nailed up' servers.  The 'cheap and dirty' answer is to use 
keyed rsync to shuttle content in and out of an image, perhaps 
from cron firing occasionally to 'somewhere else'


As part of some dissatisfaction with what was out in the 
market a few years go, we wrote an interface for deploying 
minimal install machines (initially under xen, but now also, 
and primarily under kvm) (our pmman product)

Part of the PMman machine management provides for backups 
wholly under customer control, ad hoc, and as often as a 
customer wishes. We have interfaces where a customer may 
deploy from a minimal install, take Level 0 backups, and 
maintain a series of such backups.  A machine may be cloned, 
and optionally 'handed off' to another, from backup images 
among other methods.  One can choose to either simply start 
the most recent machine shutdown image [a backup] (such backup 
is automatically produced with each interface-mediated 
restart), or to drop back to any prior 'point in time' backup 
copy, at will and under the customer's control

We use this for development purposes to 'partition' around 
problems.  Start the day; take backup 1;  work work work; take 
backup 2; work work work; take backup 3.  If all is well at 
the end of the day, thow the intermediate backups away;  if 
not, bake a point in time backup 4, and then spin up an 
earlier backup, looking for the problem creeping in.  Once 
found, treat that earlier image as a branch, and carry on.  At 
the end of the day, decide which branch to continue on 
(optionally keeping each, of course).  'weeding' and good 
naming of intermediate backup images is needed, and the 
interface provides for this

[I handed a couple of VM's and by picking through a series of 
monthly level 0 images, I was able to hand the most recent 
'rsynced' backup of the old 'hardware based' COLUG website 
over to a VM, to a group member who offered to work through 
putting it back up ... no word on progress yet.  There is an 
admixture of potentially person information useful to a 
UCE artist, so I don't feel comfortable in releasing an 
unsanitized image generally, nor really, is it all that 
unique a site.  Quirky, perhaps]

We also made a conscious decision to make our base image size 
minimal, an (initially) 4G in filesystem size, so that the 
customer can generate a ISO image of a backup, that fits on a 
standard DVD.  These ISO backup versions are able to be 
'rsynced', wholly under customer control, to taste for 
'offsite backups'. With some work -- promarily bootloader 
fixup, they then may be run elsewhere as well.  Machines may 
be 'grown' in terms of filesystem space, but really, 4G is a 
lot of space, and I find I rarely do it

The interface is set up to automatically schedule a Level 0 
backup weekly on new installs, which is included in the 
monthly price of a machine.  If a machine needs to simply 
never be rebooted, except at customer controlled intervals, 
that automatic backup may be disabled

-- Russ herrold