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
BACKUPNINJA(1) backupninja package BACKUPNINJA(1)NAME
BACKUPNINJA - A lightweight, extensible meta-backup system
"a silent flower blossom death strike to lost data."
SYNOPSIS
backupninja [ -h ] [ -d ] [ -n ] [ -t ] [ -f filename ] [ --run filename ]
DESCRIPTION
Backupninja allows you to coordinate system backups by dropping a few simple configuration files into /etc/backup.d/. Most programs you
might use for making backups don't have their own configuration file format. Backupninja provides a centralized way to configure and coor-
dinate many different backup utilities.
FEATURES
- easy to read ini style configuration files.
- you can drop in scripts to handle new types of backups.
- backup actions can be scheduled.
- you can choose when status report emails are mailed to you (always, on warning, on error, never).
- console-based wizard (ninjahelper) makes it easy to create backup action configuration files.
- passwords are never sent via the command line to helper programs.
- in order to backup a db or sql database, you cannot simply copy database files. backupninja helps you safely export the data to a format
which you can backup.
- works with Linux-Vservers.
Backup types include:
- secure, remote, incremental filesytem backup (via rdiff-backup). incremental data is compressed. permissions are retained even with an
unpriviledged backup user.
- basic system and hardware information.
- encrypted remote backups (via duplicity).
- safe backup of MySQL, PostgreSQL, OpenLDAP, and subversion databases.
- burn CD/DVDs or create ISOs.
OPTIONS -h, --help
Show summary of options
-d, --debug
Run in debug mode, where all log messages are output to the current shell.
-f, --conffile CONF_FILE
Use CONF_FILE for the main configuration instead of /etc/backupninja.conf
-t, --test
Run in test mode, no actions are actually taken.
-n, --now
Perform actions now, instead of when they might be scheduled.
--run ACTION_FILE
Runs the action configuration ACTION_FILE and exits.
CONFIGURATION
General settings are configured in /etc/backupninja.conf. In this file you can set the log level and change the default directory loca-
tions. See backupninja.conf(5).
To preform the actual backup actions, backupninja processes each action configuration file in /etc/backup.d according to the file's suffix.
See backup.d(5).
EXAMPLE USAGE
Backupninja can be used to implement whatever backup strategy you choose. It is intended, however, to be used like so:
First, databases are safely copied or exported to /var/backups. Often, you cannot make a file backup of a database while it is in use,
hence the need to use special tools to make a safe copy or export into /var/backups.
Then, vital parts of the file system, including /var/backups, are nightly pushed to a remote, off-site, hard disk (using rdiff-backup). The
local user is root, but the remote user is not privileged. Hopefully, the remote filesystem is encrypted.
In order for this to work (ie for diff-backup to run unattended), you must create ssh keys on the source server and copy the public key to
the remote user's authorized keys file. For example:
root@srchost# ssh-keygen -t rsa -b 4096
root@srchost# ssh-copy-id -i /root/.ssh/id_dsa.pub backup@desthost
Now, you should be able to ssh from user 'root' on srchost to user 'backup' on desthost without specifying a password. When prompted for a
password by ssh-keygen, just leave it blank by hitting return. The "wizard" ninjahelper(1) will walk you through these steps.
FILES
/usr/sbin/backupninja main script
/etc/backupninja.conf main configuration file; general options
/etc/cron.d/backupninja runs main script hourly
/etc/logrotate.d/backupninja rotates backupninja.log
/etc/backup.d directory for configuration files
/usr/share/backupninja directory for handler scripts
/usr/share/doc/backupninja/examples example action configuration files.
SEE ALSO ninjahelper(1), backupninja.conf(5), backup.d(5),
AUTHOR
BACKUPNINJA was written by the riseup.net collective.
riseup October 10, 2005 BACKUPNINJA(1)