Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

s3qllock(1) [debian man page]

S3QLLOCK(1)							       S3QL							       S3QLLOCK(1)

NAME
s3qllock - Make trees on an S3QL file system immutable SYNOPSIS
s3qllock [options] <directory> DESCRIPTION
S3QL is a file system for online data storage. Before using S3QL, make sure to consult the full documentation (rather than just the man pages which only briefly document the available userspace commands). The s3qllock command makes a directory tree in an S3QL file system immutable. Immutable trees can no longer be changed in any way whatso- ever. You can not add new files or directories and you can not change or delete existing files and directories. The only way to get rid of an immutable tree is to use the s3qlrm command. s3qllock can only be called by the user that mounted the file system and (if the file system was mounted with --allow-other or --allow-root) the root user. This limitation might be removed in the future (see issue 155). RATIONALE
Immutability is a feature designed for backups. Traditionally, backups have been made on external tape drives. Once a backup was made, the tape drive was removed and locked somewhere in a shelf. This has the great advantage that the contents of the backup are now permanently fixed. Nothing (short of physical destruction) can change or delete files in the backup. In contrast, when backing up into an online storage system like S3QL, all backups are available every time the file system is mounted. Nothing prevents a file in an old backup from being changed again later on. In the worst case, this may make your entire backup system worthless. Imagine that your system gets infected by a nasty virus that simply deletes all files it can find -- if the virus is active while the backup file system is mounted, the virus will destroy all your old backups as well! Even if the possibility of a malicious virus or trojan horse is excluded, being able to change a backup after it has been made is generally not a good idea. A common S3QL use case is to keep the file system mounted at all times and periodically create backups with rsync -a. This allows every user to recover her files from a backup without having to call the system administrator. However, this also allows every user to accidentally change or delete files in one of the old backups. Making a backup immutable protects you against all these problems. Unless you happen to run into a virus that was specifically programmed to attack S3QL file systems, backups can be neither deleted nor changed after they have been made immutable. OPTIONS
The s3qllock command accepts the following options: --debug activate debugging output --quiet be really quiet --version just print program version and exit EXIT STATUS
s3qllock returns exit code 0 if the operation succeeded and 1 if some error occurred. SEE ALSO
The S3QL homepage is at http://code.google.com/p/s3ql/. The full S3QL documentation should also be installed somewhere on your system, common locations are /usr/share/doc/s3ql or /usr/local/doc/s3ql. COPYRIGHT
2008-2011, Nikolaus Rath 1.11.1 August 27, 2014 S3QLLOCK(1)

Check Out this Related Man Page

EXPIRE_BACKUPS(1)						       S3QL							 EXPIRE_BACKUPS(1)

NAME
expire_backups - Intelligently expire old backups SYNOPSIS
expire_backups [options] <age> [<age> ...] DESCRIPTION
The expire_backups command intelligently remove old backups that are no longer needed. To define what backups you want to keep for how long, you define a number of age ranges. expire_backups ensures that you will have at least one backup in each age range at all times. It will keep exactly as many backups as are required for that and delete any backups that become redundant. Age ranges are specified by giving a list of range boundaries in terms of backup cycles. Every time you create a new backup, the existing backups age by one cycle. Example: when expire_backups is called with the age range definition 1 3 7 14 31, it will guarantee that you always have the following backups available: 1. A backup that is 0 to 1 cycles old (i.e, the most recent backup) 2. A backup that is 1 to 3 cycles old 3. A backup that is 3 to 7 cycles old 4. A backup that is 7 to 14 cycles old 5. A backup that is 14 to 31 cycles old Note If you do backups in fixed intervals, then one cycle will be equivalent to the backup interval. The advantage of specifying the age ranges in terms of backup cycles rather than days or weeks is that it allows you to gracefully handle irregular backup intervals. Imagine that for some reason you do not turn on your computer for one month. Now all your backups are at least a month old, and if you had specified the above backup strategy in terms of absolute ages, they would all be deleted! Specifying age ranges in terms of backup cycles avoids these sort of problems. expire_backups usage is simple. It requires backups to have names of the forms year-month-day_hour:minute:seconds (YYYY-MM-DD_HH:mm:ss) and works on all backups in the current directory. So for the above backup strategy, the correct invocation would be: expire_backups.py 1 3 7 14 31 When storing your backups on an S3QL file system, you probably want to specify the --use-s3qlrm option as well. This tells expire_backups to use the s3qlrm command to delete directories. expire_backups uses a "state file" to keep track which backups are how many cycles old (since this cannot be inferred from the dates con- tained in the directory names). The standard name for this state file is .expire_backups.dat. If this file gets damaged or deleted, expire_backups no longer knows the ages of the backups and refuses to work. In this case you can use the --reconstruct-state option to try to reconstruct the state from the backup dates. However, the accuracy of this reconstruction depends strongly on how rigorous you have been with making backups (it is only completely correct if the time between subsequent backups has always been exactly the same), so it's gener- ally a good idea not to tamper with the state file. OPTIONS
The expire_backups command accepts the following options: --quiet be really quiet --debug activate debugging output --version just print program version and exit --state <file> File to save state information in (default: ".expire_backups.dat") -n Dry run. Just show which backups would be deleted. --reconstruct-state Try to reconstruct a missing state file from backup dates. --use-s3qlrm Use s3qlrm command to delete backups. EXIT STATUS
expire_backups returns exit code 0 if the operation succeeded and 1 if some error occured. SEE ALSO
expire_backups is shipped as part of S3QL, http://code.google.com/p/s3ql/. COPYRIGHT
2008-2011, Nikolaus Rath 1.11.1 August 27, 2014 EXPIRE_BACKUPS(1)
Man Page