| Summary: | Perhaps provide some audit-able record of backups? | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | kim.moir, remy.suen |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
David Williams
I never remember how to type in short-hand comment references, such as for https://bugs.eclipse.org/bugs/show_bug.cgi?id=361707#c38 perhaps prefaced with bug instead of comment, such as bug 361707#c38 Yes, and yes. And yes. We've been using the same managed backup system since 2005. Since then, we've been receiving an email each month to remind us to test our restores. For the first few years, we did. We even brought in a blank box to simulate the case where fire would have destroyed all our hardware. But as the years passed, testing our restores went to the backburner. What came out was always what went in. Even in September our restores were tested -- they just didn't include code in the SCMs. This broke when we recently swapped the NFS servers and changed some mount points. We receive a nightly report that shows us the size of the backup. Since the daily diffs in the code repos is very, very small compared to the diffs of everything else, no red flags were raised. There was still a ton of files being backed up on dev.eclipse.org. Anyway, we've been doing everything you've suggested, more or less religiously, and that has obviously failed, so I'm open to suggestions. Perhaps in our test restore we should select files what we know should always be available in a restore (such as one directory in each SCM). Sounds like you have it covered, and this was just an hard-to-catch case that slipped though. I think you are right to add some specific tests that would have caught this particular case to your test restore ... just like we do with our code ... if a regression slips in, we try and add a junit test that would have caught the regression, just to make sure it doesn't happen again. (And, honestly, we are not that good about doing that. :) Thanks for the info. (In reply to comment #1) > I never remember how to type in short-hand comment references, such as for > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=361707#c38 > > perhaps prefaced with bug instead of comment, such as > > bug 361707#c38 bug 12345 comment 4 should work > Sounds like you have it covered, and this was just an hard-to-catch case that
> slipped though.
David, I'll close this as WORKSFORME. We'll be deploying a brand-new backups solution -- one which will give us more control -- so I'm hoping to write some automated backup tests.
|