Στις Παρασκευή 15 Σεπτέμβριος 2006 13:44, ο/η Achilleas Mantzios έγραψε: > Hi, > > Our main postgresql/jboss/lotus notes server is configured as follows. > > OS : Debian GNU linux 3.0 > PgSQL: 7.4.13 > > The FS structure of the system has as follows: > > > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/sda1 9614116 6528132 2597612 72% / > /dev/sdf 10321208 5801628 3995292 60% /raid2 > /dev/sdg 6956424 4720060 1882988 72% /raidlog > > where /dev/sda1 is the boot SCSI disk, while > /dev/sdf and /dev/sdg reside on two external EMC logical disks connected > with qlogic interfaces. > > PgSQL is installed at the default location /usr/local/pgsql, > data is on the ~ of postgres user : /var/lib/pgsql/data > > My main DB's (dynacom) data are held in > $PGDATA2 location at > /raid2/var/lib/postgres-data > > also the commit log and transaction log directories are linked to: > pg_clog -> /raidlog/sma/var/lib/pgsql/data/pg_clog > and > pg_xlog -> /raidlog/sma/var/lib/pgsql/data/pg_xlog > > We have planned to do the following task on this Sunday: > Migrate from Debian GNU linux 3.0 to SUSE SLES 9 (thats just a wierd lotus > notes "requirement"), and the sysadms have decided to do that on the same > HW, EMC disk arrays, by only replacing the root (/) disk. > > The normal (safe) way to do that would be by following the normal > backup/install/configure/restore path. > > However (just with any upgrade, and with lotus notes things get really > scary at times), there is always the possibility that the whole upgrade > procedure holds untill monday morning, when there would be an order from > our boss to rollback to the old system, or maybe repeat the same procedure > every night of the next days of the week until we succeed in Lotus Notes > upgrade! > > In this scenario,If my new suse pgsql installation was some hours alive at > the meantime, > i would have to do the whole reverse backup/restore procedure again, > and this normally takes several minutes to comlete. > The DB is something about 2.5 Gbytes on .sql dump and 6 Gbytes on disk. > > So one thought passing thru was to keep the alive postgresql dirs without > dumps/restores. That is to just retain the whole pgsql > directory /var/lib/pgsql/data on both systems, by copying back and fourth, > while leaving data $PGDATA2 (/raid2/var/lib/postgres-data) on the same EMC > disks. I guess (from the zero responses) that maybe i was not clear enuf, so i will try to set the question like this: What considerations should someone take if he is about to just cp -r <path_to_some_other_pgsql_data_path>/data . .i.e. creating the PGDATA dir *not* following the standard initdb procedure Is there any implication having to do with timestamps? modification dates? ownerships? other? if i just do cp -a <path_to_some_other_pgsql_data_path>/data . (-a implies -R) and then chown -R postgres:postgres ./data (new postgres user on the new SUSE might have a different uid/gid than the original Debian), then will i have a healthy data dir for postgresql to reliably work? I'd suppose this might work on a test system, but should someone rely on it for a critical production system? Thanx > That is no backup restore at all. > (Providing ofcourse that the /var/lib/pgsql/data owner/group are also to be > setup correctly). > > Does any one have done anything similar with (long term success), > or does anyone sees any potential problems with the later approach? > > Thanx a lot for any thoughts. -- Achilleas Mantzios
