On Mon, Sep 26, 2011 at 09:08:35AM -0430, Robert Marcano wrote: > It is not a single point of failure, your system works even with the rpm > database erased, you lose the ability to use rpm appropriately, that is > all. That's a failure, at least in a production environment; if you can't apply updates in a timely and 'appropriate' manner, you can't trust that system. Fedora isn't (or shouldn't be) a production system, but RPM is used in production systems. > What do you propose?, to have a master slave database with another > server to store the RPM DB? two directories, that does not solves the > "ohh my god, I deleted /var, parent of both rpm databases" I don't know what to propose; that's why I tossed this out. It's not only loss of the RPM database that would scrag a system--/etc/passwd & /etc/group (the shadow copies wouldn't be enough), numerous other files & directories would all drive a system to its knees. Reinstallation is not really what anyone would call a production recovery. For one thing, it brings a system "back" in a virgin state, with any generated critical data lost. Full backup recovery has also been, over the decades--and I've been there--less than an optimal solution. How often have I found that client backups hadn't been running, or were corrupted? Even if they're good, it's a long and painful downtime. Maybe a utility to which critical files/directories are identified that can take "appropriate action". Maybe appropriate action is a shadow archive on a different drive, or NAS/SAN, or another computer, or even backup media. Or maybe people shrug and say, "What we've been doing is good enough." But it should be a conscious decision, not a de facto one. Cheers, -- Dave Ihnat dihnat@xxxxxxxxxx -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
