Document Backup of database on trac-admin hotcopy

[mpotter@…]

When one performs a trac-admin hotcopy it should backup the database, unless --no-database is specified, for all db back-ends. Currently it appears to only do this for the SQLite back-end. Apparently trac-admin does have the ability to backup the database for other back-ends when performing an upgrade.

[Remy Blank]

This is already implemented on trunk​.

[Mark Potter <mpotter@…>]

Replying to rblank:

This is already implemented on trunk​.

Excellent. However, then TracBackup should reflect this.

Oh, I see 0.13/TracBackup is the newer version. However, Restoring a Backup needs work for this only describes how to restore if one is using SQLite.

[Remy Blank]

Replying to Mark Potter <mpotter@…>:

However, Restoring a Backup needs work for this only describes how to restore if one is using SQLite.

I had the impression that people using PostgreSQL or MySQL would know their tool well enough to know how to restore from an SQL dump, so we wouldn't need to document it here. This isn't the case for SQLite, as it requires no administration at all and can therefore easily be used by people with no DB background at all. But if you think it would be useful, feel free to edit that page as you see fit.

[Mark Potter <mpotter@…>]

Replying to rblank:

I had the impression that people using PostgreSQL or MySQL would know their tool well enough to know how to restore from an SQL dump, so we wouldn't need to document it here.

There are two types of people who would be using an alternative database back-end: Those who know and prefer the alternative back-end and those who need to use an alternative back-end because of some reason. The first group needs no to minimal documentation, however the second group needs moderate to detailed documentation.

Since we are in the context of backups, and thus disaster recovery planning, one wants to make sure one knows very well, or has well documented, how to restore the backups. When one is in the midst of disaster recovery, one does not want to research how to restore.

But if you think it would be useful, feel free to edit that page as you see fit.

Would love to, but alas I am in the second group. I recently (Jan 3rd) changed my back-end from SQLite to PostgreSQL because of ​Bitten performance issues. Barely know PostgreSQL, but learning.

[Christian Boos]

All the tickets for {20} from last year have probably been seen multiple times by now, yet are still to be triaged…

[mpotter@…]

Command that I just used to restore:

psql -U postgres -f postgresql.dump

Hope it worked. More details from someone more knowledgeable may be needed.

[mpotter@…]

Replying to mpotter@…:

Command that I just used to restore:

psql -U postgres -f postgresql.dump

Hope it worked.

Nope, needed to add a -d database option.

From the trac.ini, [trac], database setting:

database = postgres://user:password@localhost/database

The restore command is thus:

psql -U user -d database -f postgresql.dump

[Ryan J Ollos]

Documentation updated in TracBackup@30. I suggest using the MailingList for further discussion if you'd like to have additional recipes or best practices in the documentation.

[mpotter@…]

This appears to be the correct command for restoring a 0.12 backup, but not 1.0. Also the 0.12 version says that the backup only exists for SQLite; which is was started this ticket.

I'll fix the 1.0 and 0.12 based on this model, but someone else should review and what about other DB back-ends.

[Ryan J Ollos]

Fine if you want to try and improve the documentation, but please close the ticket afterwards. There's no point in indefinitely having an open ticket if no one is going to take responsibility for improving the documentation. Like I said, raising this on the mailing list will likely lead to more input than you'll get here.

[mpotter@…]

Believe resolved with TracBackup@31 and 0.12/TracBackup@3. However:

• Someone else should review.
• Still needs MySQL entries.

Close if you wish; I have no more skin in the game.