brandysnap.pod

NAME

brandysnap - rsync snapshot manager

SYNOPSYS

brandysnap [OPTION...]

typically

brandysnap --conf brandysnap.conf [OTHER OPTIONS...]

DESCRIPTION

This is part of the brandysnap documentation.
Copyright (c) 2011-2013  Chris Dennis  [email protected]
See the file fdl-1.3.txt for copying conditions.

Brandysnap is (yet another) script that uses rsync to create snapshot backups of files and directories.

It is still being developed, and should be considered 'beta' software. Use it at your own risk! On the other hand, it's getting better: the author already uses it 'in production'.

It is designed to be flexible and robust. In particular, it copes well with situations where snapshots are not created as regularly as they should be. This can be for a variety of reasons -- hardware failure, operator failure, weekends, holidays, someone forgot to plug in the external USB drive...

Rather than assigning 'importance' to snapshots according to when they were made (for example, keeping Friday afternoon backups for longer than Tuesday morning ones), it looks at what snapshots exist and decides if any can be deleted. If the Friday afternoon backup is missing, it will keep the nearest one it can find.

The basic rule is 'backup first, ask questions later'. Brandysnap assumes that snapshots are cheap -- in both time and space. In other words, making a snapshot is quick, and uses relatively little disk space because of the use of hard links. (Of course the first snapshot is not cheap. And snapshots over a network are never particularly quick.)

It therefore creates a new snapshot every time it is run, and then thinks about which snapshots, if any, are no longer required.

Brandysnap tries to cope with any situation. Either the source or the destination can be on a remote computer (but not both at the same time).

Brandysnap is designed to be run regularly from cron (or similar automation system). It can also be run manually if required without upsetting things.

One of the features of brandysnap is that it uses rsync to do all the work, even for deleting old snapshots locally etc. That means that, if you need root access to create the snapshot maintaining ownership and permissions, the script only needs sudo access for rsync, not for any other command nor for the script itself. (e.g. use --rsync-cmd = 'sudo rsync' and --remote-rsync-cmd = 'sudo rsync' to avoid the need for passwords [need more explanation here])

Brandysnap has been developed on Linux. It is written in Perl and uses a selection of fairly standard modules (all available in Ubuntu repositories, and no doubt elsewhere too). It relies on hard links [see ...] and will only work properly when creating snapshots on a filing system that can handle hard links, such as ext3 or ext4 [and others...].

Starting with version 0.2.19, Brandysnap can also run under Cygwin on Windows. Please note that this has not been extensively tested yet.

Lots of snapshots don't make a file more secure: if the file hasn't changed, and is the same in all snapshots, then it is only stored once on the disk. If it gets corrupted for any reason, then it will be corrupted in all snapshots. (If the file is DELETED from one snapshot, it will still exist in the others, because of the way hard links work.) Think of the whole set of snapshots as one backup, with multiple versions of files that have changed.

Very Quick Start

See the README file for brief installation instructions.

If you want to try it out without reading further, create a configuration file called brandysnap-test1.conf containing something like this:

source      = /path/to/something/to/backup
destination = /path/to/writable/directory
template    = brandysnap-test1
spec        = 4h1,1h,1d7

and then run

brandysnap --dry-run --conf brandysnap-test1.conf

The dry-run option will mean that nothing will actually be done. Once you're happy that the script won't break anything, try it without the dry-run.

For more options, run brandysnap --help.

Remote Sources and Destinations

Brandysnap assumes that any messing about with passwords has been taken care of.

In other words, it will call rsync on remote directories without supplying a password.

There are various ways of setting up rsync so that it doesn't prompt for a password -- they are not described here. [ a reference or two would be helpful here] So it's important to get the password-less access sorted out first. In fact rsync may be run many times during one run of brandysnap, and rsync would prompt for a password each time.

If the remote side of the transfer is running SSH on a non-standard port, you'll find that there is no way to include the port in the location: [email protected]:/thingy. The work-around is to create an alias in ~/.ssh/config like this:

Host eg2022
    HostName example.com
    Port 2022

and then specify the location as fred@eg2022:/thingy.

Note that it's the user running rsync that needs to modify their .ssh/config file, not necessarily the one who runs brandysnap. If, for example you use --rsync='sudo rsync', then you'll need to edit /root/.ssh/config rather than ~/.ssh/config.

This does not apply when using an rsync daemon, in which case the port can be specified as part of the location, e.g. rsync://fred\@example.com:1234/thingy.

Multiple destinations can be configured, in which case snapshots will be created on all destinations that are available. This can be used to put snapshots on several external USB drives in rotation, for example. Or you could specify one local and one remote destination for security. But note that multiple destinations won't always be in sync with each other: that's not the intention. Destinations will end up with different lists of snapshots if they are available at different times.

Preserving Ownership

In order to preserve ownership of files, brandysnap needs to be run as root or via 'sudo'.

[More detail needed here re use of sudo and remote-rsync-cmd = 'sudo rsync']

Keeping Snapshots

The number of snapshots that are made depends on how often brandysnap is run. It creates a new snapshot every time (usually).

What is more interesting is how many snapshots are KEPT. This is determined by a series of specifications, or 'specs', such as

4d5,3w3,1m11

which is a concise way of saying 'keep four snapshots a day from the last five days, then three a week for three weeks, then one a month for eleven months. If brandysnap has run successfully for the last year, then there will be at least 4x5 + 3x3 + 1x11 = 40 snapshots.

Most of the tricky stuff in brandysnap is in deciding which snapshots to keep.

Each spec is of the form

<frequency><period><count>

or

<minimum frequency> - <maximum frequency><period><count>

The 'frequency' is the number of snapshots to be kept in each period. It can be a single number from 1 to...whatever is reasonable. Or it can be a minimum-maximum range: for example 0-4 means 'keep between 0 and 4 snapshots in this period'.

Note that the frequency is not the number of snapshots that will be CREATED -- that is determined simply by how often brandysnap is run, and that will usually be down to the way that cron is configured.

The 'period' is a single letter indicating the time period. It can be one of

• h - hour

• d - day

• w - week

• m - month

• y - year

The period can be given in either upper or lower case.

The 'count' indicates the number of periods, as a number from 1 to as many as you like.

If the count is left out, the period is 'padded' to make up to the next period, working backwards in time from 'now'. For example,

4d,2w4

will be interpreted as 4d7,2w4. The 'day' specification is expanded to a week's worth of days to align with the next spec which is in weeks.

If the last spec has no count, it will be padded 'forever'. The number of snapshots will only be limited by the available disk space. And when the disk is full, the oldest snapshots will be deleted.

Snapshots also get deleted as time passes. If a day with four snapshots gets to be old enough to fall within a 2w4 spec, then the extra snapshots will be deleted.

More spec examples:

• 1d - just keep 1 backup every day, with no limit to the number of backups.

• 1h24,4d6,3w3,4m11 - one an hour for the first day, then 4 a day for the rest of the week then 3 a week for the rest of the month, then 4 a month to give a whole year of snapshots.

• 0-6d5,2-5w3,4m12 - keep up to 6 snapshots a day for five days, but consider days with no snapshots at all to be valid; then keep between 2 and 5 a week for three weeks, then keep snapshots for 12 months with 4 snapshots in each.

Managing Snapshots Manually

Snapshots are stored on the destination, each in a separate directory named template-timestamp. For example,

mightyboosh-20120515-100749
mightyboosh-20120617-145513
mightyboosh-20120726-145512
mightyboosh-20120823-145511
mightyboosh-20120914-145511

Normally, you would leave the snapshots alone, allowing brandysnap to delete them at the appropriate time.

If you wish to mark a snapshot as 'special', just rename it by adding some text to the end of the directory name. Any text will do -- make it something meaningful. For example,

mightyboosh-20120617-145513-before-upgrade

brandysnap will process the snapshot as usual, but will never delete it. (In fact it will also tweak the priority calculations to make the 'special' snapshot more likely to be kept. In other words, any non-special snapshots in the same time period are more likely to be chosen for deletion.)

There is no way to mark a snapshot as 'unimportant, delete me first', but you can delete a snapshot manually if you want to.

Definition of 'snapshot' vs full/incremental backups

Lots of snapshots don't make a file more secure: if the file hasn't changed, and is the same in all snapshots, then it is only stored once on the disk. If it gets corrupted for any reason, then it will be corrupted in all snapshots. (If the file is DELETED from one snapshot, it will still exist in the others, because of the way hard links work.)

Think of the whole set of snapshots as one backup, with multiple versions of files that have changed.

Email Notifications

Email messages can be sent if brandysnap fails. Emails are sent simply by piping them to the 'sendmail' program, which is present on most Linux systems as part of the local email server (exim, for example) and can be installed in the Cygwin environment as part of exim.

Options

All options can be given either on the command line or in the configuration file. Command line options override configuration file ones (but see below regarding multiple options). They are case-insensitive.

On the command line, options must be preceded by one or two hyphens, and can be abbreviated as long as they do not become ambiguous. An 'equals' sign (=) is optional. For example:

brandysnap --source xyz -verbose=1 --conf=bs1.conf -nocal

In the configuration file the hyphens are optional, but options can still be abbreviated. Lines beginning with '#' are considered to be comments and are ignored.

Some options (such as source and destination) can be specified more than once. In this case, command line options are added to configuration file one. For example, if the configuration files includes exclude foo and exclude bar, and you put --exclude thing on the command line, all three items (foo, bar, and thing) will be excluded.

~ can be used to specify local files and directories e.g.

--logfile = ~/brandysnap.log

The ~ will be expanded to the home directory of the user who _runs_ brandysnap. ~ can also be used on remote directories, e.g. [email protected]:~/documents. In this case, the ~ will be expanded by rsync to mean the home directory of the user specified (or implied) before the @ symbol, in this case /home/chris/. ~ can NOT be used in any of the include/exclude options.

Contexts

For more complex set-ups, options in the configuration can be nested within 'contexts'. This allows options to made specific to a particular destination or source.

For example, this snippet from a configuration file:

source /home/chris
destination /backups/one
<destination /backups/two/>
    source /home/ann
    exclude .cache
</destination>
source /home/fred
exclude tmp

Contexts are begun with <destination dest-name> or <source source-name> and finished with </destination> or </source>. Each <...> must be on a line by itself.

Source contexts can be nested within destination contexts.

The example above has two destinations. /home/chris and /home/fred (excluding tmp from both) will be copied to /backups/one. /home/ann (excluding .cache) will be copied to /backups/two.

Only certain options are valid within each context. A destination context can contain these options:

hbest dbest wbest mbest ybest
safe calendar strict
source template specs
include include-from exclude exclude-from filter
snapshot delete delete-cp
weekstart
rsync-cmd rsync-opts rsync-xopts remote-rsync-cmd
expire-old
bwlimit latest latest-copy
compress restart
allow-restart ldcount timeout-retries
all-failed some-failed
min-interval hostname
verbose loglevel debug

A source context can contain these options:

rsync-cmd rsync-opts rsync-xopts remote-rsync-cmd
include include-from exclude exclude-from filter
bwlimit
compress restart
allow-restart timeout-retries
min-interval hostname
verbose loglevel debug

OPTIONS

• Options marked with '!' in the following list are required.

• Options marked with '*' in the following list can be specified more than once.

Main options

config file !

The name of a file to look in for further options. Configuration file options will be overridden by command-line ones, irrespective of where the config option appears on the command line.

source file/dir *!

A local or remote file or directory to add to the snapshot. Examples:

source ~/Documents
source /home
source [email protected]:~/Documents

More than one source can be specified, in which case each source will be rsync'd, one at a time, to each destination in turn.

Sources can be given specific options with the following syntax:

<source ~/>
    exclude .cache
</source>

Rsync can not copy from a remote source to a remote destination, so any source/destination pairs which are both remote will be skipped.

Each source must be readable by the user who runs brandysnap.

If any files or directories within the source are not readable, brandysnap will carry on regardless.

See the section on remote authorisation.

By default, brandysnap uses the rsync options --hard-links --numeric-ids --archive --one-file-system --timeout=300, so the whole of each source will be copied recursively without following symbolic links. See the rsync-opts and rsync-xopts options for ways to change this.

destination dir *!

A local or remote directory for use as the snapshot destination. Examples:

destination /backups/
dest [email protected]:/backups

More than one destination can be specified (see source).

Destinations can be given specific options (including sources) with the following syntax:

<destination [email protected]:/backups>
    bwlimit = 2000
    remote-rsync-cmd = sudo rsync
</destination>

Each destination must be writable by the user who runs brandysnap.

See the section on remote authorisation.

template name !

The directory name of each snapshot is of the form

<template>-<timestamp>

See the Snapshot names section for more details.

Example:

template docs

specs string !

The snapshot-keeping specifications. See the Keeping Snapshots section for full details.

logfile file

The name of a file which will be used to log the output from brandysnap. Examples:

logfile /var/log/brandysnap.log
logfile ~/bs-docs.log

The user running brandysnap must have permission to create and write to the log file.

Tuning options

[no]calendar

In calendar mode, hours start on the hours, days start at midnight, weeks start on Sunday (but see the weekstart option), months start on the 1st of the month, years start on the 1st of January. Padding is added where necessary to align periods with the calendar. When calendar mode is turned off, periods are not aligned and are contiguous, ending 'now'. See the [Calendar Mode section](#calendarMode) below for further details. (default: calendar)

[no]safe

In safe mode, snapshots are only considered for deletion if the specified periods are 'complete' -- i.e. they have the required number of snapshots. If safe mode is turned off, all periods are considered complete, and extra snapshots in any of them will be deleted. See the [Safe Mode section](#safeMode) below for further details. (default: safe)

The xbest options can be used to tune the snapshot-matching algorithm which decides which snapshots should be deleted. The defaults assume that the latest snapshots within a period are the most valuable, and should be kept. Note these options only apply in calendar mode: in nocalendar mode, the oldest snapshot in a period is always preferred (otherwise snapshots would never be kept long enough to be considered by the next spec)

hbest 0..59

hbest determines the favoured minute within an hour for an hourly specification. For example, to prefer hourly snapshots created in the middle of an hours, use hbest 30. (default: 59)

dbest 0..23.9

Determines the favoured time within a day in hours. For example, to prefer daily snapshots created at 5pm, use dbest 17. (default: 23.9)

wbest 1..7

Determines the favoured day within a week, with 1=Sunday, 7=Saturday. For example, to prefer weekly snapshots created on Friday, use wbest 6. (default: 1)

mbest 1..31

Determines the favoured day within a month. For example, to prefer monthly snapshots created at the beginning of the month, use mbest 1. [This may be improved in the future to allow preferences such as 'the last Friday in the month'. If the value specified is greater than the number of days in a particular month, the last day of the month is used. To always select the last day of the month, use mbest 31. (default: 31)

ybest 1..366

Determines the favoured day within a year. In leap years, the value 366 is automatically changed to 365, so 366 always means 'the last day of the year'. For example, to prefer yearly snapshots in the middle of the year, use ybest 180. (default: 366)

min-interval 0..

Sets the minimum interval between snapshots, in minutes. This is useful on a client, such as a laptop, that is not running or not connected to the network all the time: cron can be used to schedule brandysnap frequently, and this option used to make sure that snapshots are only created every hour, say.

weekstart 1..7

Sets the first day of week. If you consider that weeks start on Monday, use weekstart 2. 1=Sunday, 7=Saturday. (default: 1)

Helpful options

help

Prints out a brief summary of options, and then stops.

version

Prints out the brandysnap version number only and then stops.

verbose 0..9

This options sets the verbosity of the printed output, on a scale from 0 to 9. Use higher values to see more about what brandysnap and rsync are doing. verbose can also be spelled verbosity (default: 3)

loglevel 0..9

Sets the verbosity level of output in the log file, on a scale from 0 to 9. If no logfile is defined, this option is effectively set to 0. (default: 3)

[no]dry-run

In dry-run mode, brandysnap goes through the motions, including checking options, sources, and destinations, as well as calling rsync with its --dry-run option, but doesn't actually create or delete any snapshots. The dry-run option is also passed through to rsync. dry-run can also be spelled dryrun. (default: nodry-run)

Rsync options

rsync-cmd path

The location of the rsync programme on your system. The default is just rsync which means brandysnap looks for rsync in your normal path. On some systems, you might need to set it to something else such as

rsync-cmd /usr/bin/rsync

(default: rsync)

[no]compress

Enable rsync compression for remote transfers. Note that this only applies compression for transfer across the network: files are expanded again on the destination. (default: compress)

Note that compression is used for any 'remote' transfer, i.e. when the source and destination are not on the same computer. On a fast local network, you may want to use --nocompress.

include/<exclude>/ pattern> *

These two options are passed through to rsync unchecked and unchanged. See the rsync documentation for details. (default: none)

include-from/exclude-from filename *

The filename is checked: if the file exists and is readable, the option is passed on to rsync (but the contents of the file are not checked).

These files can be remote, so that they can be kept on the same computer as the source they refer to. For example:

source:        fred@host1:/home/fred
exclude-from:  fred@host1:/home/fred/brandysnap.exclusions

See the rsync documentation for details. (default: none)

filter rule filename *

The filter option is passed to rsync and checked in the same way as for include-from and exclude-from.

See the rsync documentation for details. (default: none)

bwlimit <n>

Band-width limit in kbps. Set it to 0 for no limit. (default: 0)

This option can be set per destination or per source/destination combination to allow for each transfer being made by a different route. For example:

<destination: /local/dir>
        <source: /local/source>
                # no band-width limit
        </source>
        <source: rsync://remote/source>
                bwlimit: 1000
        </source>
<destination>

Tip: keep the value low (e.g. 200) if connecting over wifi to avoid swamping the connection.

rsync-opts options

Options to pass to rsync, in addition to those that brandysnap will always use (i.e. --relative and --link-dest). Use this only if you know what you are doing. (default: -aHx --numeric-ids)

rsync-xopts options

Extra options to pass to rsync. This is a convenience option to allow you to add to or override the standard options without having to remember what the standard options are. (default: none)

timeout-retries n

The number of times to retry rsync after a time-out error. This may be useful if the connection between the source and destination is unreliable. (default: 0)

Email Options

email-to address Email recipient for error messages (no default). Multiple email-to options can be given, or a comma-separated list of email addresses can be specified on a single option. email-to is required for any emails to be sent.

email-from address

Email address for From: header of email error messages. (default: current user)

email-prog server

The email program to run. The default is '/usr/sbin/sendmail -t -oi', which is installed on many Linux-based systems, and can be set up to run under Cygwin on Windows.

email-if all|any

Send email if all or any destinations failed. (default: all)

[no]email-test

Just send a message to test the other email settings. Brandsysnap will not do any other processing. (default: no)

Advanced Options

all-failed keep/delete

What to do with the snapshot if none of the sources are copied successfully. keep will keep the incomplete snapshot and mark it as 'partial' in the metadata file. This means that it will not be considered as a proper snapshot when making future decisions about which snapshots to get rid of. If you specify delete, the incomplete snapshot will be deleted immediately, in the expectation that future snapshots will be more successful. See also --some-failed. (default: delete)

[no]delete

Delete no-longer-required snapshots. If this option is turned off, brandysnap will create new snapshots but not delete any old ones. (default: delete)

[no]delete-cp

Include the 'current period' when considering which snapshots to delete. See the description of [current period](#currentPeriod) below. (default: delete-cp)

[no]expire-old

Consider _all_ snapshots (oldest first) as expirable to make room when the destination is full. (default: noexpire-old)

hostname

Override the hostname or fully-qualified domain name that is used in the snapshot path. Normally, this is the host name of the computer running brandysnap if the source is local, or the FQDN of the source if it's remote.

This option is only useful if, for example, brandysnap is running from a live CD to backup files from a non-functioning machine: you would then supply the hostname of the dead computer along with the configuration file from it so that the snapshot matches the existing ones (and so that --link-dest works properly).

(default: the hostname of the source computer)

[no]latest

If this option specified, an additional hard-linked copy of the new snapshot will be created called <template>-latest. This is designed for use with, for example, and online backup service which is configured to upload just the latest snapshot.

Note: if the destination is remote, brandysnap has to use ssh to run rsnapshot remotely: this may require extra configuration of permissions and ssh keys in order to allow brandysnap to run without prompting for passwords.

Note: latest snapshots can NOT be created on remote destinations when connecting via an rsync daemon.

(default: nolatest)

[no]latest-copy

This option specifies that the 'latest' snapshot (see above) should be created without using rsync's --link-dest option to hard-link it back to the just-created normal snapshot. In other words, the 'latest' snapshot will be a separate copy.

Note that if you change this option after a 'latest' snapshot has already been created, the choice of linking or copying will only apply to new or changed files in the snapshot. If you want to change the whole 'latest' snapshot, you will need to delete it and let brandysnap create it afresh.

This option is ignored if --latest is not also specified.

(default: no-latest-copy)

ldcount n

Specify the number of previous snapshots that rsync will search looking for identical files to hard-link to. Normally the default value of 1 is ideal. Set this value to 0 to turn off rsync's --link-dest option completely, but be aware that this will greatly increase the size of the new snapshot, and the time taken to create it (especially over the network). Values greater than 1 can be used in conjunction with [options yet to be implemented] to tune the behaviour of brandysnap. (default: 1)

[no]restart

If a previous run of brandysnap was interrupted for any reason, use this option to re-do the same snapshot (simply by relying on rsync's ability to not copy files that have not changed). Any files in the source that have changed since the previous run _will_ be updated. If more than one destination is being used, rsync will be run for _all_ destinations, even if some of them completed successfully before. --restart implies --snapshot and --min-interval=0. (default: norestart)

[no]snapshot

Create a new snapshot. If this option is turned off, no new snapshot will be created during this run of brandysnap but old snapshots may be deleted. (default: snapshot)

some-failed keep/delete

What to do with the snapshot if some of the sources are not copied successfully. See --all-failed for details. (default: keep)

status

Print a status report only, with no snapshots being created or deleted.

[no]strict

Use strict mode -- see the [Strict Mode section](#strictMode). (default: nostrict)

Development options

These options are for use by developers only.

debug section,section

Print and log debugging information. (default: (none))

test n

Run test case 'n'.

FURTHER DETAILS

Calendar mode

In 'calendar mode', which is the default, brandysnap works in terms of real weeks and months. Days always start at midnight, weeks at midnight on Sunday etc. (but see the --weekstart option).

In non-calendar mode, the specs are interpreted more simply, working backwards from the moment when brandysnap is run. There will be no gap between periods: days and weeks can start at any time, depending on when the previous spec ran out.

Safe mode

In 'safe mode', which is the default, specs will only match against the list of existing snapshots if there are enough snapshots to satisfy the spec's definition. Incomplete specs will be skipped. This has the result that brandysnap is less likely to delete snapshots. This is designed to cater for situations when brandysnap has not run successfully as often as it should have, for whatever reason. For example, because of weekends or holidays, or because the destination wasn't available because an external USB drive wasn't connected (or two or more USB drives are being used in rotation). e.g if the spec is 4d5, it's now Monday and brandysnap did not run at the weekend, then the days with fewer than 4 snapshots (i.e. Saturday and Sunday) will be skipped; counting the 5 days will start on Friday and work backwards from there. Safe mode can be turned off via the --safe option.

Strict mode

In 'strict mode', which is not the default, brandysnap will not run if there are minor problems with the specs. Normally, it will display information about how it has interpreted the specs, and carry on.

Weeks and months and years

The fact that months and years do not have whole or fixed numbers of weeks makes counting periods awkward. Brandysnap deals with this by skipping over the extra days, and only deleting their snapshots if they would have been deleted in a complete period.

Status report

Brandysnap displays a status report on all existing snapshots at the end of each run.

Snapshot names

Each snapshot is a separate directory within the destination, with a name of the form

<template>-<timestamp:YYYYMMDD-hhmmss>

where the 'template' is specified by the --template option. For example

bs1-20110616-121159

That format is fixed -- it is used to identify snapshots; any directory that doesn't match that pattern will be ignored.

Interrupt handling

Brandysnap is designed to be robust: if it receives an interrupt signal, for example if the computer is shutting down, or the user has pressed ctrl-C, while rsync is running, it traps the signal and stops cleanly.

Other notes

• Brandysnap ignores 'minor' errors from rsync, which includes errors regarding permissions. So check the output to make sure that there are no 'Permission denied' messages. If there are, you may need to run brandysnap as root -- see xxx.

KNOWN ISSUES

As of 29 August 2014 and version 0.2.19, the following issues and bugs are known.

• On the command line, rsync options --include, --exclude, --include-from, --exclude-from, and --filter are grouped together, rather than preserving their order. If you need to specify complex include/exclude/filter rules, put them in the configuration file.

• Under certain circumstances, rsync can fail if the source contains files that are hard-linked together and for which you do not have read permission. This is fixed in rsync 3.0.9 and later. You can get round it by specifying --rsync-opts with the usual options but omitting --hard-links at the cost of using more disk space.

• The fmtRange routine uses Date::Manip::Delta, which insists that February is four weeks and not one month. There may be other similar cosmetic irritations.

AUTHOR

Chris Dennis, [email protected]