On Wed, Jun 24, 2009 at 9:57 AM, Keith Lofstrom<[email protected]> wrote: > The easiest way to differentiate a directory that will be used for a > mount point, and a mounted partition on that directory, is to make > the substructure different, and rely on that.
Would it be possible to make /mnt (or /media, or wherever you want your mountpoints) be a mounted read-only filesystem itself? (say, a 2mb read-only ISO that you mount as a loopback device.) This is all conjecture, since I don't have time to try this out.... but I thought the idea was interesting. When unmounted, /mnt would be owned by root, with no write privileges for ordinary users. This would be uncommon, and probably signify a bug with fstab. When mounted, /mnt would contain a set of mountpoints, eg: /mnt/cdrom /mnt/backup /mnt/floppy ... Since /mnt is mounted read-only, you *can not* write to an un-mounted mount point--even if you're root. This *guarantees* that nothing will write to an underlying mount point instead of the mounted media, even if someone writes an app that goes through all kinds of chmod loops to enable/disable read/write access, and it doesn't require that / be mounted read-only. Once the media is mounted, I think you'd be able to write to locations inside, assuming it is mounted properly. Even if the read-only part doesn't work for some reason, making /mnt be a very, very small partition (just big enough for 6-12 mount points), would prevent any reasonable backup from running successfully. Since it would be mounted on system start-up, it's much, much less likely that it would be unmounted, and if it *was* then the mount point for the backup drive would no longer exist, causing another error. --Rogan > For example, if the > mount point directory is /media/foo, then I don't build any > subdirectories in it. Meanwhile, if the backup media mounts in > /media/foo, then it might have subdirectories ../backup/dirvish/root/ > that the backup program is looking for to do its work. When mounted, > /media/foo/backup/dirvish/root/ exists. When not mounted, it is > absent. The backup program should throw and error message and quit > when it can't find the target directory. > > The problem with this is if the backup program "helpfully" creates > all the target subdirectories when it does not find them. It should > NEVER EVER do that. If it does, that "feature" should be removed > from the source code if necessary, and the author gently flogged. > For any program based on rsync, there are switches that prevent this, > but that means delving into a vast heap of command line options. > > BTW, another pathological case is if the mounted backup directory > is treated as just another directory to be backed up. This results > in exponential growth of the backup directory with copies of itself. > Another gentle flogging opportunity. > > And as always, backup is easy (and obvious), restore is hard. It > is important to have a spare drive to restore to, and practice > restoring it, before you assume backups mean anything. Yes, a > complete backup (and how would you know?) can eventually result > in a complete restore, but some restore systems assume more > resources and rocket scientist availability than others. It is > best to learn about this before an unplanned restore blows your > schedule, your deadlines, and your sanity. > > Keith > > -- > Keith Lofstrom [email protected] Voice (503)-520-1993 > KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" > Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
