Changes

Install the [[stoney_backup:_prov-backup-rsnapshot | prov-backup-rsnasphot ]] daemon script using the package manager:

The global configuration for the provisioning daemon (which was installed with the first provisioning module and the <code>sys-apps/sst-provisioning</code> package) applies to all provisioning modules running on the server. This configuration therefore contains information about the provisioning daemon itself and no information at all about the specific modules. /etc/Provisioning/Global.conf

Install the backup utils (multiple scripts which help you to manage and monitor your backup server and backup accounts) using the package manager. For more information about the scripts please see the [[stoney_backup:_Server_set-up#stoney_backup_Service_Software _Service_Software | stoney backup Service Software]] sectionpage.

Please refer to the configuration sections for the different scripts in [[stoney_backup:_Server_set-up#stoney_backup_Service_Software _Service_Software | stoney backup Service Software]]. = stoney backup Service Software =The stoney backup Service comes along with multiple scripts which help you to manage and monitor your backup server and accounts:  We use rsnapshot - remote filesystem snapshot utility for the actual snapshots and a handful of wrapper scripts, that do things like:* Read the users and their settings from the LDAP directory.* Execute rsnapshot according to the users settings.* Write the backup quotas backup (incoming), iterations (.snapshots) and free space to the users local backupSize file and update the LDAP directory.* Inform the reseller, customer or user (depending on the settings in the LDAP directory) via mail, if the quota limit has been reached.* Depending on the users settings in the LDAP directory, warning mail will be sent to the reseller, customer or user, if a backup was not executed on time. == writeAccountSize.pl ==This script is installed to <code>/usr/libexec/backup-utils/writeAccountSize.pl</code> by the <code>sys-apps/sst-backup-utils</code> package and does the following:* Calculates the used disk space (backup and iterations) for a given account and writes the corresponding values to:*# The LDAP backend (used by the selfcare webinterface to display quota information):*#* Backup space used (sstBackupSize): The disk space the account uses for the backup itself (disk space used under the <code>incoming</code> folder of the users chroot-home directory)*#* Snapshot space used (sstIncrementSize): The disk space the account uses for the iterations (disk space under the <code>.snapshot</code> folder of the users chroot-home directory)*# The file <code>etc/backupSize</code> of the accounts chroot (used by the Sepiola Online Backup client):* Checks if the user and/or reseller must be notified that there is no more disk space left for the given account** Checks if the notification flag was passed, if not no notification will be triggered** Calculates the used disk space (backup and iterations) in percentage** Reads the notification threshold value from the LDAP backed** If the disk space used (in percentage) is bigger than the value retrieved from the LDAP backend start the [[stoney_cloud:_Notification_Architecture | notification]] process with*** Product: Given account UID*** Service: Backup*** Problem: Quota* Pod documentation:<pre>NAME writeAccountSize.pl DESCRIPTION This Script gets quota information from filesystem, size of incoming and snapshots directories, write the data to a file and the LDAP backend and sends an e-mail message for each account that is over quota to users e-mail address (from ldap directory) if notification flag is passed.  The configuration file for this script is stored in the backup-utils configuration directory (/etc/backup-utils/) and is called writeAccountSize.conf.  The script needs access to the quota program to get quota information. The script needs ldap access to get users e-mail address and quota information. The script uses syslog for logging purposes.  Command Line Interface (CLI) parameters:  -C configfile The configuration file.  -U uid The user id.  -n notification Start notification process if quota threshold is reached  -d debug Turns the debug mode on.  -h help This online help. USAGE writeAccountSize.pl -U uid [-C configuration file ] []-d debug] [-h help] [-n] CREATED 2009-04-16 michael.rhyner@stepping-stone.ch created VERSION 2009-04-16 michael.rhyner@stepping-stone.ch created 2009-04-30 michael.rhyner@stepping-stone.ch changed position based quota output parsing with correctly parsed elements 2009-06-15 michael.rhyner@stepping-stone.ch added over quota check and sending e-mail 2009-06-16 michael.rhyner@stepping-stone.ch renamed script and make it more general usable (e.g. for online backup, online storage, ...) 2009-06-17 michael.rhyner@stepping-stone.ch changed mail message to read from a text file instead from configuration parameter 2009-06-18 michael.rhyner@stepping-stone.ch corrected wrong regex to weed out the asterisk (*) in getQuotaSize 2009-06-19 michael.rhyner@stepping-stone.ch corrected wrong evaluation success from subroutines and avoid message output when not in debug mode 2009-06-22 michael.rhyner@stepping-stone.ch getQuotaSize: return immediately if no quota was set 2009-06-24 michael.rhyner@stepping-stone.ch alert when used certain percentge of allowed space instead of more than allowed space 2009-06-26 michael.rhyner@stepping-stone.ch values are presented in Gigabytes within notification message 2009-07-23 michael.rhyner@stepping-stone.ch corrected wrong syslog severities for errors 2009-07-24 michael.rhyner@stepping-stone.ch made e-mail address available within message body 2013-08-19 pat.klaey@stepping-stone.ch write quota values also to the LDAP INCORPORATED CODE Incorporate code with use:  warnings; strict; Config::IniFiles; Getopt::Std; Sys::Syslog; File::Basename; Text::Template; POSIX; Notification; PerlUtil::Logging; PerlUtil::LDAPUtil;</pre> === Configuration === /etc/backup-utils/writeAccountSize.conf<pre>[Global]INCOMING_DIRECTORY = /incomingACCOUNT_SIZE_FILE = /etc/backupSizeSNAPSHOTS = 1 [Syslog]SYSLOG = rsnapshot [Directory]LDAP_SERVER = ldaps://ldapm.tombstone.chLDAP_PORT = 636LDAP_BIND_DN = cn=Manager,dc=stoney-cloud,dc=orgLDAP_BIND_PW = <password>LDAP_BASE_DN = ou=accounts,ou=backup,ou=services,dc=stoney-cloud,dc=orgLDAP_PERSON_BASE = ou=people,dc=stoney-cloud,dc=orgLDAP_RESELLER_BASE = ou=reseller,ou=configuration,ou=backup,ou=services,dc=stoney-cloud,dc=orgLDAP_EMAIL_ATTRIBUTE = mail [Notification]EMAIL_SENDER = stepping stone GmbH Supprt <support@stepping-stone.ch>EMAIL_ALERT_THRESHOLD = 85 Salutation_Default_de-CH = Liebe Kundin / Lieber KundeSalutation_m_de-CH = Sehr geehrter HerrSalutation_f_de-CH = Sehr geehrte FrauSalutation_Default_en-GB = Dear customerSalutation_m_en-GB = Dear Mr.Salutation_f_en-GB = Dear Mrs.</pre> === Tests === /usr/libexec/backup-utils/writeAccountSize.pl -U 4000080 -d<pre>Debug modus was turned on Debug sub checkUsersHomeDirectory: $localUsersHomeDirectory: /var/backup/080/4000080/home/4000080Debug sub checkUsersHomeDirectory: The $localUsersHomeDirectory /var/backup/080/4000080/home/4000080 exists Debug sub checkUsersIncomingDirectory: $localUsersHomeDirectory: /var/backup/080/4000080/home/4000080Debug sub checkUsersIncomingDirectory: $localUsersIncomingDirectory: /incomingDebug sub checkUsersIncomingDirectory: $localIncomingPath: /var/backup/080/4000080/home/4000080/incoming Debug sub checkUsersIncomingDirectory: The $localIncomingPath /var/backup/080/4000080/home/4000080/incoming existsTotal Quota: 1048576 kilobytesTotal used Space: 0 kilobytesIncoming Size: 0 kilobytesDebug sub getSnapshotsSize: $localUsedQuota: 0Debug sub getSnapshotsSize: $localSnapshotsSize: 0Debug writeAccountSize: Working on /var/backup/080/4000080/etc/backupSizeDebug: wrote 1024 0 0 to /var/backup/080/4000080/etc/backupSizeDEBUG: Successfully executed the following modifications for entry uid=4000080,ou=accounts,ou=backup,ou=services,o=stepping-stone,c=ch: sstBackupSize => 0 DEBUG: Successfully executed the following modifications for entry uid=4000080,ou=accounts,ou=backup,ou=services,o=stepping-stone,c=ch: sstIncrementSize => 0 Alert Threshold: 85 %Calculated value: 0</pre> Now write some data (200 megaytes in this example) into the users incoming directory and then execute the script again: dd if=/dev/zero of=/var/backup/080/4000080/home/4000080/incoming/test.zeros bs=1024k count=200 chown 4000080:4000080 /var/backup/080/4000080/home/4000080/incoming/test.zeros /usr/libexec/backup-utils/writeAccountSize.pl -U 4000080 -d <pre>Debug modus was turned on Debug sub checkUsersHomeDirectory: $localUsersHomeDirectory: /var/backup/080/4000080/home/4000080Debug sub checkUsersHomeDirectory: The $localUsersHomeDirectory /var/backup/080/4000080/home/4000080 exists Debug sub checkUsersIncomingDirectory: $localUsersHomeDirectory: /var/backup/080/4000080/home/4000080Debug sub checkUsersIncomingDirectory: $localUsersIncomingDirectory: /incomingDebug sub checkUsersIncomingDirectory: $localIncomingPath: /var/backup/080/4000080/home/4000080/incoming Debug sub checkUsersIncomingDirectory: The $localIncomingPath /var/backup/080/4000080/home/4000080/incoming existsTotal Quota: 1048576 kilobytesTotal used Space: 204800 kilobytesIncoming Size: 204800 kilobytesDebug sub getSnapshotsSize: $localUsedQuota: 204800Debug sub getSnapshotsSize: $localSnapshotsSize: 0Debug writeAccountSize: Working on /var/backup/080/4000080/etc/backupSizeDebug: wrote 1024 200 0 to /var/backup/080/4000080/etc/backupSizeDEBUG: Successfully executed the following modifications for entry uid=4000080,ou=accounts,ou=backup,ou=services,o=stepping-stone,c=ch: sstBackupSize => 209715200 DEBUG: Successfully executed the following modifications for entry uid=4000080,ou=accounts,ou=backup,ou=services,o=stepping-stone,c=ch: sstIncrementSize => 0 Alert Threshold: 85 %Calculated value: 19.53125</pre>Everything seems to be working fine! == snapshot.pl ==This script is installed to <code>/usr/libexec/backup-utils/snapshot.pl</code> by the <code>sys-apps/sst-backup-utils</code> package and does the following:* Read interval parameter value passed** The interval parameter value can be daily, weekly, monthly (or yearly)* Find all backup active accounts for which the rsnapshot command must be executed (depending on the given interval)** Filter to find these accounts: <code>(&(sstBackupInterval<INTERVAL>=*)(sstIsActive=TRUE))</code> for example for the daily rsnapshot the filter is <code>(&(sstBackupIntervalDaily=*)(sstIsActive=TRUE))</code>*** In other words this means: Get me all acounts that have for <code>sstBackupInterval<INTERVAL></code> a value defined AND <code>sstIsActive</code> is set to "TRUE"* According to the interval given and the account UID calculate the rsnapshot command for all these accounts** For example*** Account UID: 4000000 *** Interval: daily*** Resulting rsnapshot command: /usr/bin/nice -n 19 /usr/bin/rsnapshot -c /etc/rsnapshot/rsnapshot.conf.4000000 daily (if you use the [[#snapshot.pl_Configuration | configuration]] below)* Execute all these commands** Use controlled parallel execution, you can specify how many commands can be executed in parallel (see [[#snapshot.pl_Configuration | configuration]] below)* Pod documentation:<pre>NAME snapshot.pl DESCRIPTION This script gets all active online backup accounts from the LDAP backend for which the rsnapshot process for the given interval must be executed. According to these accounts and the given interval, the commands to be executed are generated and finally executed. The commands can be executed in parallel, however there is a limit defined in the configuration file which limits the amount of parallel running processes. USAGE ./snapshot.pl --interval interval [--debug] [--help] OPTIONS --interval/-i interval Specifies the rsnapshot interval (can be hourly, daily, weekly, monthly or yearly)  --debug/-d Turns on debug mode  --help/-h Shows this help CREATED 2012-03-19 pat.klaey@stepping-stone.ch created VERSION 2012-03-19 pat.klaey@stepping-stone.ch created INCORPORATED CODE Incorporated code with use:  warnings; strict; Getopt::Long; Sys::Syslog; PerlUtil::Logging; PerlUtil::LDAPUtil; File::Basename; Parallel::ForkManager; Time::Stopwatch;</pre> === Configuration ===There are two things to do in this step: * Configure the rsnapshot root directory* Configure the snapshot.pl script itself ==== rsnaphot configuration directory ====The users individual rsnapshot configurations are stored under <code>/etc/rsnapshot</code>. Please make sure, that the directory exists: ls -al /etc | grep rsnapshot  drwx------ 2 root root 64 30. Aug 20:20 rsnapshot If not, create it: mkdir /etc/rsnapshot chmod 700 /etc/rsnapshot ==== snapshot.pl Configuration ====The snapshot.pl script is responsible for the execution of rsnapshot according to the users settings. /etc/backup-utils/snapshot.conf <pre>[General]MaxParallelProcesses = 5Rsnapshot_command = /usr/bin/nice -n 19 /usr/bin/rsnapshot -c /etc/rsnapshot/rsnapshot.conf.%uid% %interval% [LDAP]Host = ldaps://ldapm.tombstone.chPort = 636User = cn=Manager,dc=stoney-cloud,dc=orgPassword = <Password>CA_Path = /etc/ssl/certsAccounts_Base = ou=accounts,ou=backup,ou=services,dc=stoney-cloud,dc=org</pre> Legend: At runtime the following placeholders are replaced as follows* '''%uid%''': The backup account and login uid as a numeric number. For example: 4000205.* '''%interval%''': The backup level to be executed. Possible values are hourly, daily, weekly, monthly and yearly. === Tests ===Before adding the necessary cronjob entries, we need to make sure, that we've configured the snapshot.pl script correctly: /usr/libexec/backup-utils/snapshot.pl --interval daily -d If everything worked as planned, you should receive feedback looking roughly like:<pre>INFO: Starting rsnapshot for interval daily with maximum 5 parallel processes INFO: Executing snapshot for 4000080 INFO: Executing snapshot for 4000079 INFO: Snapshot process for 4000079 finished in 0.18 seconds with status 0 INFO: Snapshot process for 4000080 finished in 0.19 seconds with status 0 INFO: rsnapshot for all backups done. Took 0.24 seconds</pre> Just to make sure, that everything did work out fine, execute <code>writeAccountSize.pl</code> again: /usr/libexec/backup-utils/writeAccountSize.pl -U 4000080 -d<pre>Debug modus was turned on Debug sub checkUsersHomeDirectory: $localUsersHomeDirectory: /var/backup/080/4000080/home/4000080Debug sub checkUsersHomeDirectory: The $localUsersHomeDirectory /var/backup/080/4000080/home/4000080 exists Debug sub checkUsersIncomingDirectory: $localUsersHomeDirectory: /var/backup/080/4000080/home/4000080Debug sub checkUsersIncomingDirectory: $localUsersIncomingDirectory: /incomingDebug sub checkUsersIncomingDirectory: $localIncomingPath: /var/backup/080/4000080/home/4000080/incoming Debug sub checkUsersIncomingDirectory: The $localIncomingPath /var/backup/080/4000080/home/4000080/incoming existsTotal Quota: 1048576 kilobytesTotal used Space: 409600 kilobytesIncoming Size: 204800 kilobytesDebug sub getSnapshotsSize: $localUsedQuota: 409600Debug sub getSnapshotsSize: $localSnapshotsSize: 204800Debug writeAccountSize: Working on /var/backup/080/4000080/etc/backupSizeDebug: wrote 1024 200 200 to /var/backup/080/4000080/etc/backupSizeDEBUG: Successfully executed the following modifications for entry uid=4000080,ou=accounts,ou=backup,ou=services,o=stepping-stone,c=ch: sstBackupSize => 209715200 DEBUG: Successfully executed the following modifications for entry uid=4000080,ou=accounts,ou=backup,ou=services,o=stepping-stone,c=ch: sstIncrementSize => 209715200 Alert Threshold: 85 %Calculated value: 39.0625</pre> As you can see, the total used space has risen to 39.0625. === Cronjobs ===After making sure, that everything worked as planned, you can update your crontab entry: crontab -e<pre>...# Rsnapshot for all users30 22 * * * /usr/libexec/backup-utils/snapshot.pl --interval daily15 22 * * sun /usr/libexec/backup-utils/snapshot.pl --interval weekly00 22 1 * * /usr/libexec/backup-utils/snapshot.pl --interval monthly...</pre> * TBD: Maybe this is not optimal if there is a lot of data to rotate. In this case, it might be that for example weekly and daily snapshot both run at the same time what might lead to strange results. * Workarounds: ** Simple/short version: Instead one could create another wrapper script which is called everyday and does some simple logic:** Is today the first day of a month? *** Yes: Is today sunday? **** Yes: Execute monthly then weekly then daily rsnapshots using the snapshot.pl script (but wait for each interval to finish before starting the next)**** No: Execute monthly then daily rsnapshots using the snapshot.pl script (but wait for monthly interval to finish before starting the daily)*** No: Is today sunday?**** Yes: Execute weekly then daily rsnapshots using the snapshot.pl script (but wait for weekly interval to finish before starting the daily)**** No: Execute daily rsnapshots using the snapshot.pl script** Complex/long version: Adapt the snapshot.pl script and call it every day without interval parameter. The script does the logic described above.This avoids the above mentioned collision == scheduleWarning.pl ==This script is installed to <code>/usr/libexec/backup-utils/scheduleWarning.pl</code> by the <code>sys-apps/sst-backup-utils</code> package and does the following:* The basic task of this script is simple: For the given account** Check if the planned backups were started*** If not, start the [[stoney_cloud:_Notification_Architecture | notification]] process with**** Product: Given account UID**** Service: Backup**** Problem: Schedule ** Check if the planned backups finished successfully*** If not, start the [[stoney_cloud:_Notification_Architecture | notification]] process with**** Product: Given account UID**** Service: Backup**** Problem: Unsuccessful As the backup clients distributed by stepping stone GmbH upload metadata XML before (scheduling information and start time) and after (end time and backup status) the actual backup, the scheduleWarning.pl script is able to verify whether or not a planned backup has been executed and whether or not the backup was successful.  * Pod documentation<pre>NAME scheduleWarning.pl DESCRIPTION This script tests whether a planed backup was successful or not. There are two different typs of failure.  1. The Backup did not start The first type of error is that a backup is scheduled for YYYY-MM-DD at HH:MM, but the backup don't start at this specified time. A possible reason could be that the computer was shut down.  2.The backup was not successful The second type of error is that a backup started as scheduled but did not finish successfully. There are different reasons for this error.  If a backup wasn't successful the script checks which type of error occured. It reads the XML files which are stored on the server and compares the given information. If the error is detected, the script stats the norification process with the information of the error.  If a user has more than one computer backed-up, the script tests one computer after the other. The mail(s) sent by the programm also contain(s) the information which computer is affected. OPTION -U uid The -U option is required to run the script, it indicates for which uid the script is executed. USAGE scheduleWarning.pl [-U user] CREATED 2010-04-14 created Pat Kläy <pat.klaey@stepping-stone.ch> VERSION 2010-04-14 v0.01, created pkl 2010-08-24 v0.02, modified pkl New using Net::SMTP::TLS to send mails  2013-09-13 v0.03, modified pat.klaey@stepping-stone.ch Changes to use the script with the new backup infrastructure (read more information from LDAP, use Notification lib to send mails) USES strict; warnings; XML::Simple; Config::IniFiles; XML::Validator::Schema; Date::Calc qw(:all); Date::Manip; Schedule::Cron::Events; DateTime::Format::Strptime; Sys::Syslog; XML::SAX::ParserFactory; Getopt::Std; MIME::Base64; Authen::SASL; Net::LDAPS; Net::SMTP::TLS; Cwd 'abs_path'; PerlUtil::Logging; PerlUtil::LDAPUtil;</pre> === Configuration === vi /var/work/backup-surveillance/etc/config.conf<pre>[Backup]CHROOT_DIRECTORY = /var/backup/%lastthree%/%user% [XML]SCHEDULE_FILE = %homeDirectory%/incoming/%computerName%/.sepiola_backup/scheduler.xmlSCHEDULE_XSD = /etc/backup-utils/schema/scheduler_schema.xsdBACKUP_ENDED_FILE = %homeDirectory%/incoming/%computerName%/.sepiola_backup/backupEnded.xmlBACKUP_ENDED_XSD = /etc/backup-utils/schema/backupended_schema.xsdBACKUP_STARTED_FILE = %homeDirectory%/incoming/%computerName%/.sepiola_backup/backupStarted.xmlBACKUP_STARTED_XSD = /etc/backup-utils/schema/backupstarted_schema.xsd [TEMPLATE]Salutation_Default_de-CH = Liebe Kundin / Lieber KundeSalutation_m_de-CH = Sehr geehrter HerrSalutation_f_de-CH = Sehr geehrte FrauSalutation_Default_en-GB = Dear customerSalutation_m_en-GB = Dear Mr.Salutation_f_en-GB = Dear Mrs. [LDAP] SERVER = ldaps://ldapm.tombstone.chPORT = 636DEBUG = 1 ADMIN_DN = cn=Manager,dc=stoney-cloud,dc=org ADMIN_PASSWORD = <Password> BACKUP_BASE = ou=accounts,ou=backup,ou=services,dc=stoney-cloud,dc=orgPEOPLE_BASE = ou=people,dc=stoney-cloud,dc=orgRESELLER_BASE = ou=reseller,ou=configuration,ou=backup,ou=services,dc=stoney-cloud,dc=orgSCOPE = sub </pre> == checkBackups.pl ==This script is installed to <code>/usr/libexec/backup-utils/writeDate.pl</code> by the <code>sys-apps/sst-backup-utils</code> package. It is a wrapper around the above mentioned <code>writeAccountSize.pl</code> and <code>scheduleWarning.pl</code> scripts (if you configure it accordingly).* As mentioned the script is a wrapper for calling the quota and scheduler information scripts:** It gets all active backup accounts from the LDAP directory** According to the CLI parameters passed it calles for all these accounts:*** The quota checking script (this script can be defined in the configuration file, see [[stoney_backup:_Server_set-up#Configuration_6 | configuration]] section below)*** The scheduler checking script (this script can be defined in the configuration file, see [[stoney_backup:_Server_set-up#Configuration_6 | configuration]] section below)* Pod documentation: <pre>NAME checkBackups.pl DESCRIPTION This script processes all active backup accounts and checks (according to the command line options) the quota and/or the scheduled backups for the given accounts.  The script uses syslog for logging purposes.  Command Line Interface (CLI) parameters: OPTIONS --schedule/-s Checks schedule information by calling the defined script  --quota/-s Checks the quota values by calling the defined script  --notify/-n Passes the notify flag to the called scripts USAGE ./checkBackups.pl [--quota] [--schedule] [--notify]  ./checkBackups.pl --quota Checks and writes the quota for all active backup accounts. The user and/or reseller will NOT be informed if any quota threshold is reached  ./checkBackups.pl --quota --notify Checks and writes the quota for all active backup accounts. The user and/or reseller will be informed if any quota threshold is reached.  ./checkBackups.pl --schedule Checkes all active backup account if the scheduled backup was executed and successful. The --schedule option will allways trigger a notification mail to the user and/or reseller.  ./checkBackups.pl --schedule --quota Checks both, quota and schedule, for all active backup accounts. Only schedule will trigger notification mails.  ./checkBackups.pl --schedule --quota --notify Checks both, quota and schedule, for all active backup accounts. Both, quota and schedule, will trigger notification mails. CREATED 2013-09-17 pat.klaey@stepping-stone.ch created VERSION 2013-09-17 pat.klaey@stepping-stone.ch created 2013-11-19 pat.klaey@stepping-stone.ch Added options to be able to check quota, schedule or both in one run INCORPORATED CODE Incorporated code with use:  warnings; strict; Getopt::Long; Sys::Syslog; Cwd 'abs_path'; File::Basename; PerlUtil::LDAPUtil; PerlUtil::Logging;</pre> === Configuration ===In the configuration you have to define two simple things: # Which script to call for quota checks and scheduler checks# How to access the LDAP backend /etc/backup-utils/checkBackups.conf<pre>[Scripts]CheckQuotaScript = /usr/libexec/backup-utils/writeAccountSize.plCheckScheduleScript = /usr/libexec/backup-utils/scheduleWarning.pl [LDAP]Server = ldaps://ldapm.tombstone.chPort = 636Username = cn=Manager,dc=stoney-cloud,dc=orgPassword = <PASSWORD>AccountBase = ou=accounts,ou=backup,ou=services,dc=stoney-cloud,dc=org</pre> == ResellerBackupBilling.pl == == writeDate.pl ==This script is installed to <code>/usr/libexec/backup-utils/writeDate.pl</code> by the <code>sys-apps/sst-backup-utils</code> package. This is a very simple script, it simply writes the current date and time to a file on the backup server before the rsnapshots rotates the backup. This date is used by the Sepiola Online Backup Client to display the iterations and their dates.* Pod documentation: <pre>NAME writeDate.pl DESCRIPTION This script writes the current date and time into the file for each backup before the rsnapshots rotates the backup. This information is used by the Sepiola Online Backup Client.  The configuration file for this script is stored under /etc/backup-utils/writeDate.conf  The script uses syslog for logging purposes.  Command Line Interface (CLI) parameters:  -C configfile The configuration file.  -U uid The user id.  -d debug Turns the debug mode on.  -h help This online help. USAGE writeDate.pl [-C configuration_file] [-U uid] [-d debug] [-h help] CREATED 2007-09-16 michael.eichenberger@stepping-stone.ch created VERSION 2013-09-01 michael.eichenberger@stepping-stone.ch updated to reflect changes in the new backup environment  2007-09-16 michael.eichenberger@stepping-stone.ch created INCORPORATED CODE Incorporate code with use:  warnings; strict; Config::IniFiles; Getopt::Std; Sys::Syslog;</pre> === Configuration ===<pre>[Global]BACKUP_DIRECTORY = /incomingBACKUP_BACKUP_TIME_FILE = /.sepiola_backup/backupTime [Syslog]SYSLOG = rsnapshot</pre> == rsnapshot wrapper bash scripts ==