[ProgClub programming] top: st : time stolen from this vm by the hypervisor
roland at rolandturner.com
Fri Jun 7 15:45:20 AEST 2019
On 7/6/19 1:30 pm, John Elliot V | ProgClub wrote:
> On 7/6/19 3:15 pm, Roland Turner via programming wrote:
>> On 7/6/19 11:52 am, John Elliot V | ProgClub wrote:
>>> I guess one thing that springs to mind to prefer my current setup to
>>> your suggested approach is a mild concern over vendor lock-in. All other
>>> things being equal I prefer pursuing approaches which would work equally
>>> well if I shifted to another cloud provider... 'rsync' fits that bill,
>>> whereas 'aws' CLI does not.
>> You have a credible cloud provider in mind who does not provide SAN-like
>> services of this type? Even Rackspace CloudServers CBS does this, albeit
>> with some bizarre rough edges.
> My point was simply that I'd have to manually integrate each one.
> Whereas with 'rsync' each cloud provider exposes a uniform interface
> (i.e. SSH over TCP/IP).
Sure. There are costs associated with migration. Given the low frequency
with which you'll bear these, this does not seem like an important
concern. Portability is for canoes etc.
>>> * Fiddling: pursuing your suggestion, which I do agree is potentially a
>>> good approach, would also leave data restores being a little bit fiddly.
>>> At the moment if I need a backed up file I can just SSH in to one of my
>>> backup hosts and find it in the file-system. Restoring/mounting
>>> snapshots is not quite so straight-forward. That is not to say that it's
>>> impossible though, of course.
>> Erm that's an archive requirement (which you indicated that you had
>> another solution for), not a backup requirement. Restoring volume
>> snapshots is fairly quick and extraordinarily simple:
>> * Create a volume from the snapshot. (This will take several minutes
>> to complete.)
>> * Stop the failed instance.
>> * Detach its root volume.
>> * Attach the new volume.
>> * Start the failed instance.
>> Even doing what you describe is pretty straightforward:
>> * Create a volume from the snapshot.
>> * Attach the new volume to a convenient instance and mount it.
>> * Extract whatever you need.
>> * Unmount, detach, and delete.
> Sure. But those things are slightly more difficult than accessing a
> backup file system which is already mounted.
Is this an important concern?
>> Do you need to do either of these things more than once a year?
> Certainly not. It seems a bit silly to say, but hopefully never!
And I want a pony. How frequently do you _*actually*_ need to rely
upon backups? You've been running servers for at least a decade? (Two?)
You have empirical data to work with on this question.
(In my case, over a 30 year period: two total losses (one media failure,
one administrative error) and about half-a-dozen individual file
You appear to be suffering the hyperbolic discounting in reverse: you're
valuing distant, very rare gains very highly, and present definite
losses (implementation costs) very low.
> Also, if I do need to access a backup file, there very well may be some
> level of urgency; in which case waiting for snapshots to turn into
> volumes or whatnot might be an exacerbating delay...
For example? (You're not running life-critical services; a few minutes
delay once a year is neither here nor there.)
1: Not an actual desire, for illustrative purposes only, YMMV.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the programming