From: Holger P. <wb...@pa...> - 2009-05-22 21:57:26
|
Hi, Daniel Carrera wrote on 2009-05-22 23:02:57 +0200 [Re: [BackupPC-users] Noob questions]: > Les Mikesell wrote: > > [...] > >> On my system the disk always reliably mounts on /media/Daniel. [...] > > > > But unless you do a custom install, that's not where backuppc is going > > to want it. > > ??? I might have misunderstood something. Don't I just set > $Conf{topDir} = '/media/Daniel/Backups' ? starting from version 3.2.0beta0 you do, before that, you don't. > >> Anyways, checking that the backup directory exists seems like a no > >> brainer, even if you don't think specifically of the case of external disks. > > > > External or not, yanking a disk out from under a running application is > > a little drastic. > > Well, in my mind, I wasn't planning to do it while it's actually backing > up. [...] > > > umount should not be able to complete if any process has open files or > > its working directory. [...] > > So there's no problem. If I try to unmount and BackupPC is doing > something I just wait until it's finished and then take the laptop to > the bedroom. BackupPC will be doing something: having the log file opened (unless, of course, you configure that to be somewhere else). The working directory of the daemon is /, not $topDir, but what about BackupPC_trashClean? What other parts of BackupPC might be affected? Remember, this is a server process (someone already mentioned that), that tries to run a schedule (much like cron). Right, BackupPC has nothing that needs to run at a particular time, except for BackupPC_nightly (which the administrator configures to run at a particular time, when it will not disturb backups - other than that it only needs to run regularly). It is not designed to run atop a potentially unavailable storage structure, and redesigning it to do so is more than a matter of a quick check or addition of a hook. > [...] > Jeffrey just gave another, perhaps more typical example: The backup > media might be an NFS share. You might want to check if that is mounted > or not (and possibly try to mount it if it's not). No, I would not call that typical. Backing up to an NFS volume is never the preferred solution. It might be necessary or "good enough" for some people. Better solutions like ATAoE or iSCSI suffer from the same problem (as do external SCSI devices whose power might be turned off). Temporary unavailability of the storage device is more likely if it is not an integral part of the server hardware. I'm not sure how the kernel handles that for ATAoE/iSCSI. Pretty much any file can be on such remote hardware without the application being aware. Should all applications be re-designed to take that into account? "Retry your database transaction on monday, the hard disk seems to have left for the weekend"? It *might* be easier to do for BackupPC than for a database, but that, in itself, is not an argument to actually do it. In my opinion, it simply does not make sense [as Jeffrey pointed out while I was writing this]. Regards, Holger |