/Library/Server/Calendar and Contacts
was using up 233MB. While that might not seem a lot - when keeping 10 copies, it will still use some disk space.
So then it came to my mind, that, when time passes by, there are a lot of events, that nobody no longer cares about.
Surely there must be some kind of mechanism to remove those expired events.
So I went looking around on the command line.
What I found were these commands:
calendarserver_command_gateway
calendarserver_config
calendarserver_diagnose
calendarserver_export
calendarserver_gather_logs
calendarserver_import
calendarserver_manage_principals
calendarserver_purge_attachments
calendarserver_purge_events
calendarserver_purge_principals
For us especially interesting are these:
You can get some help by calling them with the '-h' option
calendarserver_export
Usage: calendarserver_export [options] [input specifiers]
This tool reads calendar data from a series of inputs and generates a single
iCalendar file which can be opened in many calendar applications.
This can be used to quickly create an iCalendar file from a user's calendars.
This tool requires access to the calendar server's configuration and data
storage; it does not operate by talking to the server via the network. It
therefore does not apply any of the access restrictions that the server would.
As such, one should be mindful that data exported via this tool may be
sensitive.
Please also note that this is not an appropriate tool for backups, as there is
data associated with users and calendars beyond the iCalendar as visible to the
owner of that calendar, including DAV properties, information about sharing, and
per-user data such as alarms.
Options:
-D, --debug Debug logging.
-f, --config= Specify caldavd.plist configuration path. [default:
/Applications/Server.app/Contents/ServerRoot/private/etc/caldavd/caldavd-apple.plist]
--help Display this help and exit.
-c, --collection= Add a calendar collection. This option must be passed after
--record (or a synonym, like --user). for example, to
export user1's calendars called 'meetings' and 'team',
invoke 'calendarserver_export --user=user1
--collection=meetings --collection=team'.
-r, --record= Add a directory record's calendar home (format:
'recordType:shortName').
--version Display Twisted version and exit.
-u, --user= Add a user's calendar home (shorthand for '-r
users:shortName').
-d, --directory= Specify output directory path.
-o, --output= Specify output file path (default: '-', meaning stdout).
--uid= Add a calendar home directly by its UID (which is usually a
directory service's GUID).
This will thus allow you to export a users calendar from the server. Might be interesting one day.
But what I'm really looking for are these:
calendarserver_purge_events
calendarserver_purge_events -h
usage: calendarserver_purge_events [options]
Remove old events from the calendar server
options:
-h --help: print this help and exit
-f --config : Specify caldavd.plist configuration path
-d --days : specify how many days in the past to retain (default=365)
-n --dry-run: calculate how many events to purge, but do not purge data
-v --verbose: print progress information
-D --debug: debug logging
So this is the command to delete old events.
In my case, when calling it using the 'dry run' option, I got this response:
calendarserver_purge_events -nv
NOTICE: there is no transaction in progress
(Dry run) Searching for old events...
6590 events are older than 20140625T000000
So, I could easily remove 6950 events that are more than one year old! Cool.
calendarserver_purge_attachments
Now I know that some people often attach documents to events. So we should clean up those as well.
So let's check this out:
calendarserver_purge_attachments -h
usage: calendarserver_purge_attachments [options]
Remove old or orphaned attachments from the calendar server
options:
-h --help: print this help and exit
-f --config : Specify caldavd.plist configuration path
-u --uuid : target a specific user UID
-d --days : specify how many days in the past to retain (default=365) zero means no removal of old attachments
-n --dry-run: calculate how many attachments to purge, but do not purge data
-v --verbose: print progress information
-D --debug: debug logging
In our case, a dry run returns this:
calendarserver_purge_attachments -nv
NOTICE: there is no transaction in progress
(Dry run) Searching for orphaned attachments...
(Dry run) Searching for old dropbox attachments...
(Dry run) Searching for old managed attachments...
Orphaned/Old Attachments by User:
+-----------------+---------------+-------------+--------------+--------------+---------------+--------------+---------------+------------+-------------+
| User | Current Quota | Orphan Size | Orphan Count | Dropbox Size | Dropbox Count | Managed Size | Managed Count | Total Size | Total Count |
|-----------------+---------------+-------------+--------------+--------------+---------------+--------------+---------------+------------+-------------|
| wiki-haxxxxxxxxx | 18883053 | 817155 | 6 | 18062725 | 332 | 0 | 0 | 18879880 | 338 |
|=================+===============+=============+==============+==============+===============+==============+===============+============+=============|
| Total: | | 817155 | 6 | 18062725 | 332 | 0 | 0 | 18879880 | 338 |
+-----------------+---------------+-------------+--------------+--------------+---------------+--------------+---------------+------------+-------------+
That means there are quite some attachments that can be removed that are older than one 365 days.
So, time to write a script that will perform these cleanups once a month.
Hooray!
No comments:
Post a Comment