Do you do backups with Confluence up?

[unixg...@gmail.com]

We were doing MySQL database dumps then filesystem backups from 15
minutes later. Both with Confluence up. Since this was the middle of
the night, we figured it wasn't a problem.

I'd used this method to copy/clone our production systems to
development in the past, but hadn't looked at the content in great
detail.

When I was on vacation, other people tried to use it to recover a
production system crash. It didn't completely work and it was rather
painful to fix.

If you have attachments in your filesystem, how do you back up each of
them?

And do you shut down Confluence every time you do it?



--
You received this message because you are subscribed to the Google Groups "Confluence in the (real) Enterprise" group.
To post to this group, send email to enterprise...@googlegroups.com.
To unsubscribe from this group, send email to enterprise-confl...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/enterprise-confluence?hl=en.

[Igor Minar]

Can you describe the issues that were found during the recovery process?

In our case the attachments are stored in the db, so with a single
mysql dump (while confluence is running) we get everything (minus
config files in the confluence home directory, but those are stored in
our SCM repo).

The only db dumps we do with Confluence offline are during upgrades.

If we had attachments stored in the filesystem then I'd use ZFS and
its snapshots to do instant backups.

/i

[Justin]

We have a warm server that just rsync's the entire Atlassian directories and replicates mysql to keep it in sync. On the primary server, backups of the db are done once a day.  Attachments are backed up to tape nightly.  On the warm server, MySQL is backed up hourly and the entire atlassian directory is tar'd up nightly.  The script keeps 2 weeks of database backups and 3 days worth of the Atlassian install on locally on the server -- would just be easier to recover from there than tape.  The other advantage to that tar directory is syncing up testing environment just involves importing db and extracting the tar files.  All of this is performed without shutting down Confluence and I have been able to restore many times without a problem.

I was looking into other options but priorities got in the way, but honestly this has worked great for a few years.

Hope this helps.


Backups are done to tape nightly on the production server

[Igor Minar]

Oh.. and forgot to mention that we run a confluence cluster (which as
of version 3.1.1 has been working reliably for us finally). The nodes
are configured in primary/failover configuration. So in case the
primary goes down the second node will take over the traffic (unless
the crash of primary takes down the failover too :-P, but that hasn't
happened recently).

MySQL db is configured similarly as master/slave with automatic
replication, but manual switch to failover. This is however useful
only if whatever corrupted the primary db can't spread to the slave
via replication. That's why we still need nightly db dumps.

/i

[unixg...@gmail.com]

We are using a NetApps, and I use the snapshots performed at midnight
to retrieve and database

I don't know exactly what issues were found while I was gone. They
found that all our database dumps since our upgrade a month ago were
bad.

2 weeks ago, I copied in the nightly snapshot and got the DBA's to
load in the previous night's database dump.

At the time it appeared to work. However, while I was gone, people
familiar with the content logged in to my copy and saw that things
were missing. I ran the database integrity tool and a number of items
were mismatched.

[Igor Minar]

Do you run the mysql dump in a transaction? If you do, then I can't
think of a way that the data could get corrupted.

[unixg...@gmail.com]

I'm asking our DBA's for the command...

I'm wondering if there would be some way that Confluence might have
something in memory cache that had't been sent to the database yet.

Igor Minar wrote:
> Do you run the mysql dump in a transaction? If you do, then I can't
> think of a way that the data could get corrupted.
>
>

Alice

[Igor Minar]

Even if that was true (which I doubt) the db state should have been consistent.