25 Bře
2021
25 Bře
'21
14:01
Hello, Jaromir, Paul, and all:
For what is worth.
Here at NIC-CR, we've had this problem. We have held FRED at 2.32, for
not having problems with our production platform. In some months we will
migrate FRED to the newest version, I think.
At 2.32 when doing a periodic pg_dump backup, it backups
everything....except the object_registry table.. FOr correcting this we
use a PostgreSQL COPY of that table.
Now, at new versions, that we have tested (last one I tested is 2.443 or
so), after doing this and migrating the database to the new version
format, the backup is completely clean. You can restore the database
without problem.
Also, I had problems with such that tables with a previos version.
Perhaps I can help Paul. I think they are prettry static tables, right,
Jaromir?. So perhaps I can help Paul (Paulus?) offline?
Best regards, and hoping that this is fixed soon.
Mario Guerra
NIC-CR - Costa RIca
El 25/3/21 a las 02:18, Jaromir Talir escribió:
On Thu, 2021-03-25 at 08:24 +0200, Dr Paulos Nyirenda
wrote:
On 23 Mar 2021 at 22:40, Jaromir Talir wrote:
Ok, this is it.
This procedure is meant to be run only when there is an upgrade from
one version to another. It is not intended to be used for regular
backup/restore operations. During an update between versions, there may
be a new versions of mail templates and this is included in the
upgrade. It is true that if there has been local changes in templates,
they could be overwritten.
If there are some local modifications, we suggested to keeping a diff
of those local modification in some sql update and apply this diff at
the end of upgrade procedure. Since it is expected that this upgrade is
done once a year, in theory, this should not create a big burden.
But we are also investigating possibility how to solve this issue in
better way. Component for handling notification is going through major
refactoring at the moment and templates for communication will be
managed differently. We will check possibility how to completely remove
dealing with content of those templates during update.
Regards,
Jaromir
Hi Paulos,
if you are doing restore of database, you should probably do this
into
empty database or if you have "create database" as part of dump,
you
can remove database at the destination system completely.
Ahhh ... but I do, I
think, as follows:
########### stop fred servers first
#sudo -u postgres psql
#DROP DATABASE fred;
#CREATE DATABASE fred;
#\q
# psql -U fred -d fred -f fred-backup-file.
Does this not satisfy this ?
After this I do a db upgrade:
# su - postgres -c "/usr/sbin/fred-dbmanager upgrade"
which runs ok, however, the resulting mail_template table is
different from the one in the dump, all the cz entries show up again
and the English editing is gone. Regards,
Paulos
=============================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD
http://www.nic.mw
SDNP: http://www.sdnp.org.mw
Tel: +265-(0)-882 089 166
Cell: +265-(0)-888-824787
WhatsApp: +265-(0)-887386433
_______________________________________________
fred-users mailing list
fred-users(a)lists.nic.cz
https://lists.nic.cz/mailman/listinfo/fred-users Regards,
Jaromir
On Tue, 2021-03-23 at 10:28 +0200, Dr Paulos Nyirenda wrote:
> On 19 Mar 2021 at 14:06, Jaromir Talir wrote:
>
>> Hi Paulos,
>>
>> I'm not sure if I got it right. There are two scenarios:
>>
>> 1/ You do DUMP + RESTORE and information in restored tables is
>> different than in original table.
>>
>> This would be weird. I can only imagine that DUMP failed or was
>> incomplete but otherwise there should be no issue
> This is the issue. When we do a DUMP and RESTORE, the
> mail_template
> on the system on which we do a restore remains the same, it is
> not
> updated from the restore in the DUMP.
>
> As such we have to manually edit it again to get it updated.
>
>> 2/ You do DUMP + modification + RESTORE and modification is not
>> in
>> restored tables.
> We do not do a modification after doing the DUMP.
>
>> This is also correct since modifications are not included in
>> DUMP.
>> I suggest to make backup via DUMP after modification of those
>> tables.
> After a bit of reading and when I get the time, I am now going to
> try to do a data only dump of the mail_template table with the
> data
> that we want and then see if I canm restore that data only after
> the
> restore using the aproach suggested in the attached advice, would
> that work ?
>
> Regards,
>
> Paulos
> =============================
> Dr Paulos B Nyirenda
> NIC.MW & .mw ccTLD
> http://www.nic.mw
> SDNP: http://www.sdnp.org.mw
> Tel: +265-(0)-882 089 166
> Cell: +265-(0)-888-824787
> WhatsApp: +265-(0)-887386433
>
>
>> Regards,
>> Jaromir
>>
>> On Thu, 2021-03-18 at 15:39 +0200, Dr Paulos Nyirenda wrote:
>>> Good afternoon,
>>>
>>> I am having trouble maintaing my English version of
>>> mail_template table in the FRED database backup and restore,
>>> can
>>> you help ?
>>>
>>> I often need to backup the FRED registry system database and
>>> I
>>> am using
>>> #pg_dump -U fred fred > fred-backup-file.sql
>>>
>>> To restore that database I use
>>> #sudo -u postgres psql
>>> #DROP DATABASE fred;
>>> #CREATE DATABASE fred;
>>> #\q
>>> #psql -U fred -d fred -f fred-backup-file.sql
>>>
>>> However, I find in almost all cases that I lose any updates
>>> that
>>> I made on mail_template table when I restore this way on the
>>> new
>>> restoration.
>>>
>>> Is there a way that I can keep the most resent mail_template
>>> updates between backup and restore?
>>>
>>> I have tried to save the mail_template using a dump like
>>> #pg_dump -U fred fred -t mail_template > fred-mail_template-
>>> bkp.sql
>>> but I am unable to restore this because I get the error that
>>> there are too many dependencies on mail_template when I try
>>> to
>>> drop the table and then use pg_restore -t.
>>>
>>> So, what is the best way of moving with my desired
>>> mail_template
>>> in FRED?
>>>
>>> Can I do this even between different schemas of backup and
>>> restore ?
>>>
>>> Regards,
>>>
>>> Paulos
>>> =============================
>>> Dr Paulos B Nyirenda
>>> NIC.MW & .mw ccTLD
>>> http://www.nic.mw
>>> SDNP: http://www.sdnp.org.mw
>>> Tel: +265-(0)-882 089 166
>>> Cell: +265-(0)-888-824787
>>> WhatsApp: +265-(0)-887386433
>>>
>>>
>
>
>
> The following section of this message contains a file attachment
> prepared for transmission using the Internet MIME message format.
> If
> you are using Pegasus Mail, or any other MIME-compliant system,
> you
> should be able to save it or view it from within your mailer. If
> you
> cannot, please ask your system administrator for assistance.
>
> ---- File information -----------
> File: postgreSQL-backup and restore-table-data-
> makandracards.pdf
> Date: 18 Mar 2021, 16:58
> Size: 285252 bytes.
> Type: Unknown
Virus-free. www.avg.com