On 2009-Mar-25 07:21:37 -0500, Jack L. Stone ja...@sage-american.com wrote:
However, last month upon upon upgrading those servers from FBSD-6.3px
(RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers
had a similar problem as the original poster while the other half did not.
...
At 09:45 AM 3.25.2009 -0500, Peggy Wilkins wrote:
Jack L Stone ja...@sage-american.com writes:
I've been watching this thread with some interest since we've had some
similar problems with dump/restore which we use every morning via cron
scripts on a number of servers to produce
At 07:53 AM 3/26/2009, Jack L. Stone wrote:
SOLUTION
The clones are a very important pasrt of our backup program.
Since the
dump side of the problems simply stuck and provided no error
message at all
and the errors from any restores were not useful, our only solution
was to
Hi,
I followed this thread out of interest since I do not suffer from this error.
But I wonder if truss could shed some light into this issue. If for
example a dump hangs at 99%, it might be an idea to set up truss to
trace the dump process. Yes, this will produce lots of output, but
maybe it
At 07:57 AM 3.26.2009 -0400, Mike Tancsa wrote:
Thanks for the reply. Forgot to mention, our machines are all i386 with the
problem -- so are the ones without the problem.
Yes, I found that patch too and tried it on one of the servers -- no joy.
Guess we'll continue to wait also for now. Maybe
At 08:08 AM 3/26/2009, Jack L. Stone wrote:
Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).
Unless the filesystem is very busy, you will get your data backed up.
If you have things like databases, I still
Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).
Unless the filesystem is very busy, you will get your data backed up.
If you have things like databases, I still would not trust
snapshots.
Uh. If
At 10:01 AM 3/26/2009, Peter Schuller wrote:
Unless the filesystem is very busy, you will get your data backed up.
If you have things like databases, I still would not trust
snapshots.
Uh. If backuping up a live database from a snapshot is not
trustworthy, either the snapshot facility is
Peter Schuller wrote:
Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).
Unless the filesystem is very busy, you will get your data backed up.
If you have things like databases, I still would not trust
... or the database is configured in a risky way... But judging by
this thread, it seems dump with -L is indeed broken for some
people. Hence, I suggested dumping the database using the database's
backup tools and trying dump without -L
Well, if dump -L is really broken I'd recommend just
The issue with backing up a database live comes in when the filesystem
where the database and transaction log files are DIFFERS. You can get
into a pathological case in that instance.
If the transaction log and database itself are both on the same
snapshotted entity (that is, the
Peter Schuller wrote:
The issue with backing up a database live comes in when the filesystem
where the database and transaction log files are DIFFERS. You can get
into a pathological case in that instance.
If the transaction log and database itself are both on the same
snapshotted entity
To add to this what SHOULD (ha!) work is to dump the database partition
FIRST and THEN dump the Transaction Log partition.
Depending on how the database works; specifically when old data in the
log may or may not be expunged. You could do this with PostgreSQL by
using it's PITR support for
Peter Schuller wrote:
To add to this what SHOULD (ha!) work is to dump the database partition
FIRST and THEN dump the Transaction Log partition.
Depending on how the database works; specifically when old data in the
log may or may not be expunged. You could do this with PostgreSQL by
Hi..
On Thu, 26 Mar 2009, Peter Schuller wrote:
Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).
Unless the filesystem is very busy, you will get your data backed up.
If you have things like databases, I
On 2009-03-26 02:45:45PM +, Jake Scott wrote:
Absolutely. You really must use a tool that interacts with the database to
perform the backup. Most commercial DBs have hooks that allow the backup
routines to call out to custom snapshot facilities. One would usually
request a backup
Exactly right - if you backup a database by relying on storage snapshots
then the best you will end up with is a database that needs to be
recovered when you restore those volumes (crash consistent). That's not a
good place to be in when your production DB has just blown up.
If you have a
Jake Scott wrote:
That said there are plenty of other reasos to use proper dump tools
(data portability, confirming the ability to actually read all rows
from a table, using a more often exercised code path and perhaps less
likely to have edge case bugs, etc).
Absolutely. You really must
However, whether either of these approaches is sufficient is another
matter. One of the real problems with live transaction processing
systems is a means to know when there is a failure exactly what you
lost. This is not a trivial problem to solve and requires plenty of
thought before
At 09:32 AM 3.26.2009 -0400, Mike Tancsa wrote:
At 08:08 AM 3/26/2009, Jack L. Stone wrote:
Yes, but it's for running a dump on a (L)ive FS and just spits out warnings
to that effect and has no effect on solving the problem(s).
Unless the filesystem is very busy, you will get your data backed
At 10:15 AM 3.26.2009 -0400, Mike Tancsa wrote:
At 10:01 AM 3/26/2009, Peter Schuller wrote:
Unless the filesystem is very busy, you will get your data backed up.
If you have things like databases, I still would not trust
snapshots.
Uh. If backuping up a live database from a snapshot is
Absolutely. You really must use a tool that interacts with the database
to perform the backup. Most commercial DBs have hooks that allow the
backup routines to call out to custom snapshot facilities. One would
usually request a backup through the database, which would then freeze IO
to
At 10:46 AM 3.26.2009 -0500, Karl Denninger wrote:
Jake Scott wrote:
That said there are plenty of other reasos to use proper dump tools
(data portability, confirming the ability to actually read all rows
from a table, using a more often exercised code path and perhaps less
likely to have
On Thu, 2009-03-26 at 14:45 +, Jake Scott wrote:
..
Absolutely. You really must use a tool that interacts with the database
to perform the backup. Most commercial DBs have hooks that allow the
backup routines to call out to custom snapshot facilities. One would
usually request a
At 07:25 PM 3.25.2009 +1030, Daniel O'Connor wrote:
On Wednesday 25 March 2009 18:37:17 Bartosz Stec wrote:
Yes, dump is broken for you, deal with it. It is quite possible your FS
is corrupt, and/or your disk is damaged.
..and/or it is some other hardware problem, maybe you also should test
Jack L Stone ja...@sage-american.com writes:
I've been watching this thread with some interest since we've had some
similar problems with dump/restore which we use every morning via cron
scripts on a number of servers to produce bootable clones as part of our
backup program.
26 matches
Mail list logo
