Edgewall Software
Modify

Opened 11 years ago

Closed 8 years ago

#10529 closed enhancement (worksforme)

Document Backup of database on trac-admin hotcopy

Reported by: mpotter@… Owned by: Ryan J Ollos
Priority: normal Milestone:
Component: database backend Version: 0.12.2
Severity: normal Keywords: documentation
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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.

Attachments (0)

Change History (14)

comment:1 by Remy Blank, 11 years ago

Resolution: worksforme
Status: newclosed

This is already implemented on trunk.

in reply to:  1 ; comment:2 by Mark Potter <mpotter@…>, 11 years ago

Keywords: documentation added
Resolution: worksforme
Severity: majornormal
Status: closedreopened
Summary: Backup database on trac-admin hotcopy with all backendsDocument Backup of database on trac-admin hotcopy

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.

in reply to:  2 ; comment:3 by Remy Blank, 11 years ago

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.

in reply to:  3 comment:4 by Mark Potter <mpotter@…>, 11 years ago

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.

comment:5 by Christian Boos, 10 years ago

Milestone: undecided

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

comment:6 by mpotter@…, 9 years ago

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.

in reply to:  6 comment:7 by mpotter@…, 9 years ago

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

comment:8 by Ryan J Ollos, 8 years ago

Milestone: undecided1.0.3

comment:9 by Ryan J Ollos, 8 years ago

Owner: set to Ryan J Ollos
Status: reopenedassigned

comment:10 by Ryan J Ollos, 8 years ago

Milestone: 1.0.3
Resolution: worksforme
Status: assignedclosed

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.

comment:11 by mpotter@…, 8 years ago

Resolution: worksforme
Status: closedreopened

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.

comment:12 by Ryan J Ollos, 8 years ago

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.

comment:13 by mpotter@…, 8 years ago

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.

comment:14 by Ryan J Ollos, 8 years ago

Resolution: worksforme
Status: reopenedclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Ryan J Ollos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.