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 sh
> Jack L Stone 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. Have been
On 2009-Mar-25 07:21:37 -0500, "Jack L. Stone" 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.
...
>the next day, and
At 09:45 AM 3.25.2009 -0500, Peggy Wilkins wrote:
>> Jack L Stone 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
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 solu
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 give
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 fo
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.
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
s
> ... 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 j
> 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 s
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 (th
> 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 ex
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
using
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 st
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 hav
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 use
> 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 befo
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 ba
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
> 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
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
>>> like
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 b
26 matches
Mail list logo