Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 12/12/2011 10:39 PM, markw at mohawksoft.com wrote: > Why would that happen? That's what I don't understand. If you have a > mission critical failure of this sort, then you fall back to a previous > backup as your beginning and do a full backup at this point. You don't > ignore the failure and proceed business as usual. Follow closely: * Create file #1 * Do full dump. Contains file #1 data and directory metadata. * Create file #2. * Do incremental dump #1. Contains file #1 directory metadata, file #2 data and directory metadata. * Create file #3. * Make incremental dump #2. Contains file #1 and #2 directory metadata, file #3 data and metadata. * Disaster strikes! The server explodes in a ball of flame, or gets eaten by Gojira or something. You replace the hardware and prepare for recovery. * Restore full dump to new server. You now have file #1 complete. * Attempt to restore incremental dump #1 and find that it is unusable. If you stop at this point then there are 2 files missing. * Restore incremental dump #2. At this point you have all of file #1 and file #3 along with their directory metadata. You only have file #2's directory metadata. Specifically, an ls on that directory will show that file #2 is there, but the inode list isn't accurate as there is no file data on that volume. The file system is in an inconsistent state at this point. How does your backup system recover from this?
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |