On 22Sep2008 09:51, Theodore Tso <tytso@xxxxxxx> wrote: [...snip a lot of remarks I entirely agree with...] | > But a database is... more complicated [...] | | Sure, but the solution may not scale so well for folks who are backing | up 50+ machines and backing up all of /usr, including all of the | distribution maintained files, or for folks who never delete any of | their past incremental backups. Sure. There's plenty of stuff I wouldn't back up this way. | > For Richard's benefit, I can report that I've used the hard link backup | > tree approach extensively on ext3 filesystems made with default mke2fs | > options (i.e. no special inode count size) and have never run out of | > inodes. Have you actually done some figuring to decide that running out | > of inodes is probable? | | Sure, but how many machines are you backing up this way, and how many | days of backups are you keeping? My own current use case is pretty small, and they're not machines but data trees (eg static web site trees, configuration files etc - they have well defined and simple permissions and usually low change rates so I don't need "machine image" quality, just data integrity). Some 10s of GB and 4 months of dailies; I do prune old trees, but for overall disc space reasons, not lack of inodes. Only half of this is on ext3; the other is on xfs which I think has dynamic inode allocation. Probably we need to know more about Richard's plans. | And have you ever tried running | "e2fsck -nftt /dev/hdXX" (you can do this on a live system if you | want; the -n means you won't write anything to disk, and the goal is | to see how much memory e2fsck needs) to make sure you can fix the | filesystem if you need it? I'll queue this up as something to try, though the backups themselves are replicated to elsewhere anyway. Cheers, -- Cameron Simpson <cs@xxxxxxxxxx> DoD#743 _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
