linux800 | cron / crontab / at

cron daemon / crontab command / at

achtergrond: ubuntu howto cron
achtergrond: tuxradar.com/content/automate-linux-cron-and-anacron

opdracht:

schrijf een script (als root) dat een backup maakt van /home en alles erin op een extra harde schijf (/dev/sdb), geformatteerd in ext3 en gemount in /backup. Gebruik tar.bz2 formaat.

aanmaken van de harde schijf

In uw virtuele omgeving verbind je een extra harde schijf van 100GB aan je virtuele machine.

Na opstarten doe je een gdisk op die harde schijf en maak je 1 enkele partitie over de volledige schijf:

$ sudo parted /dev/sdb print
[sudo] password for bert: 
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
 
Number  Start   End    Size   File system  Name              Flags
1      1049kB  107GB  107GB  ext3         Linux filesystem

Formatteer daarna in ext3 of ext4:

$ sudo mkfs.ext3 /dev/sdb1

mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
6553600 inodes, 26214139 blocks
1310706 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
800 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
4096000, 7962624, 11239424, 20480000, 23887872
Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Maak een mountpoint, /backup
plaats /dev/sdb1 daarna in /etc/fstab:

$ sudo mkdir /backup

$ sudo vim /etc/fstab

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=990f7a23-5364-4fde-8edf-83e213ae88af /               ext4    errors=remount-ro 0       1
 
# we zetten de 100G backup disk onderaan ...
/dev/sdb1   /backup ext3    defaults    0   0

Met sudo mount -a kun je de fstab testen,
met df kun je zien of het gelukt is ...
Als je linux heropstart, ben je zeker dat het gelukt (of mislukt) is ...

crontab

We voeren crontab -e uit als sudo:

$ sudo crontab -e

# Edit this file to introduce tasks to be run by cron.
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
*   *   *   *   *      /etc/cron.d/backup.sh

* every minute
* every hour
* every day of month
* every month
* every day of week (0 is sunday, 1 is monday, ... 6 is saturday and 7 is sunday again)

We hebben een script, backup.sh geplaatst in de directory, /etc/cron.d

#!/bin/bash
#
# starting backup
filenaam="homebu-$(date +"%m-%d-%Y-%T").tar.bz2"
echo $filenaam
tar -cvjf /backup/$filenaam /home
# end of backup

let op: crontab zal meestal geen script uitvoeren zonder shebang
#!/bin/bash
in het script introduceren we een variabele filenaam waarin we een datum en tijd plaatsen.
filenaam="homebu-$(date +"%m-%d-%Y-%T").tar.bz2"
de eigenlijke backup is een tar -cvj die een bzip2 bestand maakt van /home,
tar -cvjf /backup/$filenaam /home

test je script met:
$ sudo /etc/cron.d/backup.sh

crontab testen

Om te testen hebben we daarnet aan crontab -e gevraagd
om elke minuut een backup uit te voeren ...
We kunnen vervolgens kijken of die backup gemaakt is ...

je kan dat monitoren met watch:
user@mint18-201 ~ $ watch ls -l /backup/
```
Every 2.0 seconds: ls -l /backup/                       Wed Jan 24 14:27:48 2018
total 1280132
-rw-r--r-- 1 root root 738612817 Jan 24 14:14 homebu-01-24-2018-14:12:07.tar.bz2
-rw-r--r-- 1 root root 152361487 Jan 24 14:18 homebu-01-24-2018-14:17:49.tar.bz2
-rw-r--r-- 1 root root 152359444 Jan 24 14:22 homebu-01-24-2018-14:22:01.tar.bz2
-rw-r--r-- 1 root root 152359444 Jan 24 14:24 homebu-01-24-2018-14:24:01.tar.bz2
-rw-r--r-- 1 root root 115130368 Jan 24 14:25 homebu-01-24-2018-14:25:01.tar.bz2
drwx------ 2 root root     16384 Jan 24 14:00 lost+found
```
zodra de backups verschijnen (dat gaat nogal vooruit, ... elke minuut) ...
kun je de crontab instellen op een normale dagelijkse of wekelijkse frequentie ...
```
#
# m h  dom mon dow   command
23 4 * * 2 /etc/cron.d/backup.sh
 
## 23 4 * * 2: elke dinsdag om 4u23 am
```
Tenslotte moeten we de tar-backup onderzoeken:
- eerst met tar -tvf <filenaam>
- daarna kun je een restore doen naar een testdirectory om zeker te zijn dat je backup compleet is
- backups moeten regelmatig worden getest en gerestored om te zien of het proces loopt zoals voorzien.
  
  In mijn geval zijn er problemen: een backup testen of terugzetten loopt vast op de ":" (dubbele punt) in de file-naam:
  
  $ sudo tar -tvf homebu-01-24-2018-14\:34\:01.tar.bz2
  tar: Cannot connect to homebu-01-24-2018-14: resolve failed
  
  Dit kunnen we oplossen met de optie --force-local:
  $ sudo tar -xvf "homebu-01-24-2018-14:34:01.tar.bz2" --force-local
alternatieve crontab

De crontab -e is een per user scheduler.
Deze kan je eventueel vinden in /var/spool/cron/crontabs/

De /etc/crontab is een algemene scheduler, vooral voor systeemprocessen. Die zou je ook kunnen gebruiken voor backups.

Een moderne linux-omgeving voorziet bovendien in enkele directories:
```
drwxr-xr-x 2 root root 4096 Jan  4 02:30 /etc/cron.daily
drwxr-xr-x 2 root root 4096 Dec 13  2016 /etc/cron.hourly
drwxr-xr-x 2 root root 4096 Dec 13  2016 /etc/cron.monthly
drwxr-xr-x 2 root root 4096 Sep 19 10:06 /etc/cron.weekly
```
waarin je gratuit scripts kunt plaatsen die dan zonder enige configuratie automatisch elk uur, dag week of maand worden uitgevoerd. Het volstaat je script in één van deze directories te plaatsen. Het script moet dan wel aan enkele stricte voorwaarden voldoen:

As you've probably seen in the comments to your question, the cronjobs in /etc/cron.hourly (and the other, similar directories) are executed by run-parts. run-parts is a little picky about filenames. By default it doesn't execute files whose filenames contain anything other than (all of those from ASCII)
- uppercase letters
- lowercase letters
- digits
- underscores
- dashes ("minus signs")
  
  So if your script has a filename of for example "myscript.sh", it just is ignored, because run-parts does not like the dot. --- Apr 19 '15 at 22:05 -- Henning Kockerbeck

syslog

tail -f laat dynamisch de staart van een bestand zien, in dit geval de /var/log/syslog

$ sudo tail -f /var/log/syslog

Dec  1 10:03:01 apa-ub14 CRON[1953]: (CRON) info (No MTA installed, discarding output)
Dec  1 10:11:01 apa-ub14 cron[1945]: (*system*) RELOAD (/etc/crontab)
Dec  1 10:17:01 apa-ub14 CRON[1977]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  1 10:23:15 apa-ub14 kernel: [59003.611457] init: cron main process (1945) killed by TERM signal
Dec  1 10:23:15 apa-ub14 cron[2115]: (CRON) INFO (pidfile fd = 3)
Dec  1 10:23:15 apa-ub14 cron[2116]: (CRON) STARTUP (fork ok)
Dec  1 10:23:15 apa-ub14 cron[2116]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
Dec  1 10:25:01 apa-ub14 CRON[2199]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  1 10:28:01 apa-ub14 cron[2116]: (*system*) RELOAD (/etc/crontab)
Dec  1 10:30:01 apa-ub14 CRON[2333]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  1 10:35:01 apa-ub14 CRON[2362]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

In deze syslog is o.a. te zien wanneer er een cron-job wordt uitgevoerd.
In het voorbeeld werd cron.hourly verchillende keren kort na mekaar uitgevoerd. Om te debuggen hadden we in de /etc/crontab telkens opnieuw het tijdstip van aangepast:

17 * * * * root cd / && run-parts --report /etc/cron.hourly

Hoewel cron-hourly perfect liep werd ons script toch niet uitgevoerd.
Het script was executable, eigendom van root, had een shebang, maar bevatte een punt in de filenaam, en dat mag niet ...

at

http://www.computerhope.com/unix/uat.htm