You saved me a bunch of time; I was
planning to test my backup and restore later today. Thanks!
It occurred to me that the backups won't be as useful as I thought. I'd need to make sure that the PGs hadn't moved around after the backup was made. If they had, I'd spend a lot of time tracking down the new locations and manually rsyncing data. Not a big deal on a small cluster, but it get harder as the cluster gets larger. Now that I look at the dumps, it looks like PG locations are one of the things missing. Binary backups of the MON directories are fine. All of the problems I've seen on the list occurred during cluster upgrades, so I'll make the backup part of my upgrade procedure instead of a cron. If I wanted to restore a backup, what would be required? Looking at http://eu.ceph.com/docs/v0.47.1/ops/manage/grow/mon/#removing-a-monitor-from-an-unhealthy-or-down-cluster, I don't see a monmap directory inside /var/lib/ceph/mon/ceph-#/ anymore. I assume it went away during the switch to LevelDB, so I think I'll need to dump a copy when I make the binary backup. I'm assuming there is some node specific data in each MON's store. If not, could I just stop all monitors, rsync the backup to all monitors, and start them all up? I'm not using cephx, but I assume the keyrings would complicate things. It would probably be easiest to make binary backups on all of the monitors (with some time delay, so only one is offline at a time), then start them up in newest-to-oldest-backup order. Or I could use LVM snapshots to make simultaneous backups on all monitors. Thanks for the info. On 08/08/13 15:21, Craig Lewis wrote: |
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com