Ask stupid questions and you'll get a stupid answers, was: Technological advantages over Linux

Aryeh Friedman aryeh.friedman at
Fri Jul 24 20:53:04 UTC 2020

On Fri, Jul 24, 2020 at 4:01 PM Steve O'Hara-Smith <steve at> wrote:

> On Fri, 24 Jul 2020 14:09:15 -0400
> Aryeh Friedman <aryeh.friedman at> wrote:
> > spent 7 weeks denying that it was needed because they did block level
> disk
> > backups (I would love to hear from any DBA who would trust such
> > backups!!!)
>         Well so long as it streamed all changes to the backup in real time
> and was guaranteed never to lose a block no matter what then I might trust
> it for hot swap purposes but not for disaster recovery.

That is the reason why we requested replication not backup!  (see below for
what the hosting company absolutely refused to understand/believe)

Did I mention that the database *MUST* stay up 24/7 since it is receiving
real-time cardiac data for patients that are known (or at least strongly
suspected to have heart conditions serious enough to need potential
emergency open heart surgery) and the DB recieves over 1000 updates every 3
seconds that need to be processed in near real time?  So no it is not
possible to take it down (as is recommended by the MySQL manual and/or
almost every blog out there)...  So in order to avoid corrupting the DB on
restore by backup incomplete transactions the only way is to lock the
tables before backing it up (something that can only be done inside the DB
not external with block only backups)... only problem here is it takes
longer to back them up then 3 seconds and the client software is written by
complete morons (who for example never even heard of concurrency as far we
can tell) and thus just silent drops any data that can not be written to
the DB (they blindly assume everything is a successful write).  So
therefore block backups are completely out the question (btw the DB is 21
GB and growing at 500 MB a month)...

Let add one more complication the client wants us to auto populate the
MySQL DB from our webapp DB which is on a physically separate machine, but
refuses to buy a second license for the device DB software and thus we are
forced to do our development/alpha testing on live data (i.e. we *MUST*
have completely working backups made every 15 mins or so).

In short this is the kind of project that makes the developers (us) need
the devices we have connected to our webapp much sooner than later (if we
ever needed them at all outside of this project).    Grey hair would be the
best possible outcome of this project!

Aryeh M. Friedman, Lead Developer,

More information about the freebsd-questions mailing list