From: | Matt <matt(at)ymogen(dot)net> |
---|---|
To: | Murthy Kambhampaty <murthy(dot)kambhampaty(at)goeci(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: LVM snapshots |
Date: | 2003-03-15 23:45:05 |
Message-ID: | 3E73BB01.2020403@ymogen.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Murthy Kambhampaty wrote:
>Backup restore has been tested so far by restoring a table and comparing the
>contents; they were identical. Thanks to rsync performance is fantastic
>compared to pgdump to a file (my past e-mail to the list will give some idea
>of the problems we've had with that). I'd be interested in comments on the
>strategy and the script itself.
>
>
>
Many thanks for the detailed info!
As I see it the discussion so far says:
1. The strategy should theoretically work (coy comments in the docs
notwithstanding)
2. It works for you in practice
3. It works very efficiently when using rsync
The only potential missing piece that I can see is some thorough
stress-testing, such as running say 50 updates/second against a
multi-table DB while the snapshotting and backup takes place, then
testing the snapshotted DB. Is the DB you have been backing up under
significant load when you take the snapshot?
If the theory can be robustly demonstrated to work in practice (which
you may have already done) then I say this strategy needs to be
recognised in the docs (or at least the techdocs) as a valid and useful one.
From | Date | Subject | |
---|---|---|---|
Next Message | R Blake | 2003-03-16 03:56:02 | help? trouble setting Shared Memory parameters in OSX kernel |
Previous Message | Christophe Folliet | 2003-03-15 17:06:26 |