what's wrong.
--
Ragnar Kjørstad
; primarely because
it's impossible to do manual UNDO. (what if a transaction updated an
index but didn't get around to update the table, or the other way around
- how do you fix that manually?)
--
Ragnar Kjørstad
Big Storage
on startup
Indeed re-loading a pg_dump will take lots more time, but that's why I
want my DB backups to be done both as a ready-to-roll set of file images
as well as a pg_dump :-)
Yes, the more redundant backup-solutions the better :)
--
Ragnar Kjørstad
Big Storage
-companies (Oracle?) were
going to start doing this on the default configuration because it would
eliminate all the problems with clueless users that found a free
partition and started using it for something else :)
--
Ragnar Kjørstad
Big Storage
in solaris8 does optional logging)
Wasn't this question originally about FreeBSD anyway?
I suppose it was.
--
Ragnar Kjørstad
Big Storage
. (it is better
than a filesystem backup in this regard, but there are still
version-incompabilities that have to be fixed manually)
--
Ragnar Kjørstad
Big Storage
involved in the
sync writes. (the writes to the actual files happens asyncrounous).
So there is a theoretical improvement, but it's not likely to show up on
a typical SQL-benchmark...
--
Ragnar Kjørstad
Big Storage
19, 2002 at 23:53:14 (+0200), Ragnar Kjørstad wrote: ]
Subject: Re: Backing up PostgreSQL?
By this definition postgresql is consistant at all times
That's simply not possible to be true. PostgreSQL uses multiple files
in the filesystem namespace to contain its data -- sometimes even
.
Of course the directory argument doesn't make sense for pg_dump, but
one could use a syntax like /database-name or /database-name/table
to specify what to back up.
--
Ragnar Kjørstad
Big Storage
On Fri, Jun 14, 2002 at 09:15:15PM -0400, Greg A. Woods wrote:
[ On Saturday, June 15, 2002 at 00:45:12 (+0200), Ragnar Kjørstad wrote: ]
Subject: Re: Backing up PostgreSQL?
snapshots (LVM snapshots) are not supposedly nearly instantaneous, but
instantaneous. All write-access
On Thu, Jun 13, 2002 at 04:57:16PM -0500, Kirk Strauser wrote:
At 2002-06-13T21:26:22Z, Ragnar Kjørstad [EMAIL PROTECTED] writes:
The easiest way to snapshot the filesystem is to use a logical volume
manager (LVM or EVMS on linux) and then do:
1. take database offline
2. take
that if data changes postgresql needs to keep two branches, and it
will require extra diskspace and I suppose also introduce overhead to
other processes?
Of course, if the database is mostly read-only this is just a minor
problem, but that's true for snapshot-backups as well.
--
Ragnar Kjørstad
Big
a crash /
powerfailure.
--
Ragnar Kjørstad
Big Storage
regular backup.
The easiest way to snapshot the filesystem is to use a logical volume
manager (LVM or EVMS on linux) and then do:
1. take database offline
2. take snapshot
3. take database online
4. backup from snapshot
5. remove snapshot
--
Ragnar Kjørstad
Big Storage
On Tue, Aug 14, 2001 at 09:05:25AM -0500, Katrinka Dall wrote:
FAILED AND STRANGE DUMP DETAILS:
/-- xx.p /dev/sdb1 lev 0 FAILED [data write: File too large]
Does it fail after backing up 2 Gigabyte?
It sounds like you don't have Large File Support (LFS).
sendbackup: start
On Tue, Aug 14, 2001 at 10:34:58AM -0400, Rivera, Edwin wrote:
i've been trying to get amanda to backup one of my DEC boxes for the past
couple of days, but i can't seem to get it going on the 5.1 flavor. works
fine on my 4.0f and 4.0d boxes. am i doing something weird?.. i've tried
all
16 matches
Mail list logo
