[ProgClub programming] top: st : time stolen from this vm by the hypervisor

Roland Turner 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[1]. 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.)

- Raz

1: Not an actual desire, for illustrative purposes only, YMMV.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.progclub.org/pipermail/programming/attachments/20190607/cd1fa082/attachment-0001.html>

More information about the programming mailing list