On Wed, Jun 20, 2012 at 11:36 AM, Dennis Herbrich <dennis@xxxxxxxxxxxxx> wrote: > On Wed, Jun 20, 2012 at 10:36:17AM +0200, Arno Gaboury wrote: >> add this in my */etc/rc.local.shutdown*: >> >> |*echo "Copying LOGs..." >> >> now=`date +"%Y%m%d_%Hh%M"` >> mkdir -p /logs_backup/$now >> cp -Rp /var/log/* ~/backup/logs_backup/$now/* >> >> My ~ folder is on another HD. >> >> Will this script be enough to do the job? > > Depends on your job description. ;) > > If your system crashes (hah, as if ever!) or becomes unresponsive, you're > screwed, as rc.local.shutdown is likely not called and your logs are lost after > reboot. This is probably not what you want. > > If you've got suitable network infrastructure, you may want to instruct > syslog-ng to forward the logs to a remote logging daemon in addition to the > local ramdisk. This is nice and clean, given a stable network connection to a > suitable machine to work as a logging daemon. > > Just a desktop machine or no independent server available? It may be enough for > your purposes to use logrotate to copy over the logs properly to a safe mass > storage device in regular intervals. Maybe hourly. This, however, won't help > you much in case of kernel panic, either. It's better than rolling your own > regular rotation with cron and shell, though. > > Feeling old-school? Setup a printer to receive critical(!) logs. For bonus > points, use a 9-pin matrix printer. If you hear it screeching, you know > something's horribly wrong. Free notification to boot! > > Alternatively, if you need critical(!) log messages even after a crash, you may > want to configure syslog-ng to only(!) log such critical messages directly to a > file on you mass storage device. Output should be scarce as not to unduly put > your flash memory under stress. > > Lots of possibilities. Choose wisely. > > Best regards, > Dennis > > -- > "Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen." > Dr. Wolfgang Schäuble, Bundesinnenminister (14.10.08, TAZ-Interview) > > 0D21BE6C - F3DC D064 BB88 5162 56BE 730F 5471 3881 0D21 BE6C If you use systemd with its accompanying log daemon (the journal), it does not write its logs to disk by default. It only does so if the directory /var/log/journal/ exists. Journald keeps volatile logs in /run/log/journal, which is on a tmpfs. If you create /var/log/journal/, you can use the MaxLevelStore= setting (/etc/systemd/journald.conf) to control which messages get written to disk, e.g. critical messages only. All other messages are still recorded in volatile memory. You can still run a classical syslog daemon and have the journal forward to it, implementing all the fancy network or printer stuff above. Of course, the problem with any syslog (or journal) approach is that it does not capture applications writing to /var/log/ directly.
