Innobackupex is excellent- we use it- but it's not as trivial as a tar copy
of the mysql directory (shut the database down first). For example, you may
end up using the database username/password on the command line in your
scripts (which you should probably avoid). Also, according to the man
On Fri, Sep 25, 2015 at 10:50 AM, Raymond Burns Jr.
wrote:
> I didn't run a backup of the database because of all the great responses
> from people.
Oh dear Lord man! If running mysql, shut the database down and tar up the
/var/lib/mysql directory (or whatever you have in
On Fri, Sep 25, 2015 at 09:01:29AM -0700, Stephen Thompson wrote:
>
>
>
> I run daily backups of my database and had finished my monthly full run
> for September, so I was technically covered. However I was not looking
> forward to restoring a 900+Gb mysql database from a text dump which on
Good luck.
Kern
On 15-09-25 12:02 PM, Stephen Thompson wrote:
>
> So far so good. Minor snafu on my part when updating database, but I'm
> running 7.2 now. Looking good so far. Will find out more when hundreds
> of jobs run tonight.
>
> Stephen
>
>
>
> On 09/24/2015 08:40 AM, Stephen Thompson
Help?
Well, the compile and install went fine, but the update tables script is
having issue.
I was running 7.0.5 before. Not sure what database version, but likely
whatever was appropriate to 7.0.5.
First time I ran script as su'ed user which caused this...
--
Altering mysql tables
I run daily backups of my database and had finished my monthly full run
for September, so I was technically covered. However I was not looking
forward to restoring a 900+Gb mysql database from a text dump which on
my system would take days, if not an entire week. The last time I had
to
Spoke too soon, I see what's going on, I was running update script from
new location (7.2.0) and it's referencing old location (7.0.5) and
running the wrong mysql script.
On 09/25/2015 08:34 AM, Stephen Thompson wrote:
>
> Help?
>
> Well, the compile and install went fine, but the update
Did you run a backup of the database?
If not, I bet you were terrified with all the errors :)
Same thing happened to me going to 7.0.5, and it sent me for a frenzy. I
didn't run a backup of the database because of all the great responses from
people.
When is the 7.2.0 rpm expected? Not running
So far so good. Minor snafu on my part when updating database, but I'm
running 7.2 now. Looking good so far. Will find out more when hundreds
of jobs run tonight.
Stephen
On 09/24/2015 08:40 AM, Stephen Thompson wrote:
>
> All,
>
> I typically patch bacula pretty frequently, but I saw
Thanks, I'll be upgrading soon.
What known bugs are in the update_bacula_tables scripts?
thanks,
Stephen
On 9/24/15 10:51 PM, Uwe Schuerkamp wrote:
> On Thu, Sep 24, 2015 at 08:40:05AM -0700, Stephen Thompson wrote:
>>
>> All,
>>
>> I typically patch bacula pretty frequently, but I saw the
On Fri, Sep 25, 2015 at 06:43:57AM -0700, Stephen Thompson wrote:
>
> Thanks, I'll be upgrading soon.
>
> What known bugs are in the update_bacula_tables scripts?
>
> thanks,
> Stephen
>
Hi Stephen,
not real "bugs", but rather some weird messages about the EOT tag not
being found and other
All,
I typically patch bacula pretty frequently, but I saw the somewhat
unusual notice on the latest release notes that warns it may not be
ready for use in production. How stable is it? I don't really have the
resources to test this out, but rather would have to go straight to
production
Hello,
We put a caution message in every release, particularly for new features
which are generally tested but not always tested in production.
Normally most of the issues turn up for non-Linux distributions where we
either have not tested or have tested less than Linux.
Version 7.2.0 is as
On Thu, Sep 24, 2015 at 08:40:05AM -0700, Stephen Thompson wrote:
>
> All,
>
> I typically patch bacula pretty frequently, but I saw the somewhat
> unusual notice on the latest release notes that warns it may not be
> ready for use in production. How stable is it? I don't really have the
>
14 matches
Mail list logo