Table Of Contents

Important Rules to Avoid Losing Data

Most S3QL backends store data in distributed storage systems. These systems differ from a traditional, local hard disk in several important ways. In order to avoid loosing data, this section should be read very carefully.

Rules in a Nutshell

To avoid losing your data, obey the following rules:

  1. Know what durability you can expect from your chosen storage provider. The durability describes how likely it is that a stored object becomes damaged over time. Such data corruption can never be prevented completely, techniques like geographic replication and RAID storage just reduce the likelihood of it to happen (i.e., increase the durability).

  2. When choosing a backend and storage provider, keep in mind that when using S3QL, the effective durability of the file system data will be reduced because of S3QL’s data de-duplication feature.

  3. Determine your storage service’s consistency window. The consistency window that is important for S3QL is the smaller of the times for which:

    • a newly created object may not yet be included in the list of stored objects
    • an attempt to read a newly created object may fail with the storage service reporting that the object does not exist

    If one of the above times is zero, we say that as far as S3QL is concerned the storage service has immediate consistency.

    If your storage provider claims that neither of the above can ever happen, while at the same time promising high durability, you should choose a respectable provider instead.

  4. When mounting the same file system on different computers (or on the same computer but with different --cachedir directories), the time that passes between the first and second of invocation of mount.s3ql must be at least as long as your storage service’s consistency window. If your storage service offers immediate consistency, you do not need to wait at all.

  5. Before running fsck.s3ql or s3qladm, the file system must have been left untouched for the length of the consistency window. If your storage service offers immediate consistency, you do not need to wait at all.

The rest of this section explains the above rules and the reasons for them in more detail. It also contains a list of the consistency windows for a number of larger storage providers.

Consistency Window List

The following is a list of the consistency windows (as far as S3QL is concerned) for a number of storage providers. This list doesn’t come with any guarantees and may be outdated. If your storage provider is not included, or if you need more reliable information, check with your storage provider.

Storage Provider Consistency
Amazon S3 in the US standard region Eventual
Amazon S3 in other regions Immediate
Google Storage Immediate
RackSpace CloudFiles Eventual

Data Consistency

In contrast to the typical hard disk, most storage providers do not guarantee immediate consistency of written data. This means that:

  • after an object has been stored, requests to read this object may still fail or return the prior contents for a little while.
  • after an object has been deleted, attempts to read it may still return the (old) data for some time, and it may still remain in the list of stored objects for some time.
  • after a new object has been created, it may still not be included when retrieving the list of stored objects for some time.

Of course, none of this is acceptable for a file system, and S3QL generally handles any of the above situations internally so that it always provides a fully consistent file system to the user. However, there are es a hard disk of dynamic, infinite capacity that can be accessed from any computer with internet access running Linux, FreeBSD or OS-X. S3QL is a standard conforming, full featured UNIX file system that is conceptually indistinguishable from any local file system. Furthermore, S3QL has additional features like compression, encryption, data de-duplication, immutable trees and snapshotting which make it especially suitable for online backup and archival. S3QL is designed to favor simplicity and elegance over performance and feature-creep. Care has been taken to make the source code as readable and serviceable as possible. Solid error detection and error handling have been included from the very first line, and S3QL comes with extensive automated test cases for all its components. Features ======== * **Transparency.** Conceptually, S3QL is indistinguishable from a local file system. For example, it supports hardlinks, symlinks, ACLs and standard unix permissions, extended attributes and file sizes up to 2 TB. * **Dynamic Size.** The size of an S3QL file system grows and shrinks dynamically as required. * **Compression.** Before storage, all data may compressed with the LZMA, bzip2 or deflate (gzip) algorithm. * **Encryption.** After compression (but before upload), all data can AES encrypted with a 256 bit key. An additional SHA256 HMAC checksum is used to protect the data against manipulation. * **Data De-duplication.** If several files have identical contents, the redundant data will be stored only once. This works across all files stored in the file system, and also if only some parts of the files are identical while other parts differ. * **Immutable Trees.** Directory trees can be made immutable, so that their contents can no longer be changed in any way whatsoever. This can be used to ensure that backups can not be modified after they have been made. * **Copy-on-Write/Snapshotting.** S3QL can replicate entire directory trees without using any additional storage space. Only if one of the copies is modified, the part of the data that has been modified will take up additional storage space. This can be used to create intelligent snapshots that preserve the state of a directory at different points in time using a minimum amount of space. * **High Performance independent of network latency.** All operations that do not write or read file contents (like creating directories or moving, renaming, and changing permissions of files and directories) are very fast because they are carried out without any network transactions. S3QL achieves this by saving the entire file and directory structure in a database. This database is locally cached and the remote copy updated asynchronously. * **Support for low bandwidth connections.** S3QL splits file contents into smaller blocks and caches blocks locally. This minimizes both the number of network transactions required for reading and writing data, and the amount of data that has to be transferred when only parts of a file are read or written. Development Status ================== After two years of beta-testing by about 93 users did not reveal any data-critical bugs, S3QL was declared **stable** with the release of version 1.0 on May 13th, 2011. Note that this does not mean that S3QL is bug-free. S3QL still has several known, and probably many more unknown bugs. However, there is a high probability that these bugs will, although being inconvenient, not endanger any stored data. Please report any problems on the `mailing list `_ or the `issue tracker `_. ./usr/share/doc/s3ql/html/_sources/fsck.txt0000644000000000000000000000064611603353245017540 0ustar rootroot.. -*- mode: rst -*- Checking for Errors =================== If, for some reason, the filesystem has not been correctly unmounted, or if you suspect that there might be errors, you should run the `fsck.s3ql` utility. It has the following syntax:: fsck.s3ql [options] This command accepts the following options: .. pipeinclude:: ../bin/fsck.s3ql --help :start-after: show this help message and exit ./usr/share/doc/s3ql/html/_sources/index.txt0000644000000000000000000000045311736327107017722 0ustar rootroot.. -*- mode: rst -*- =================== S3QL User's Guide =================== .. toctree:: :maxdepth: 2 about installation backends durability mkfs adm mount special umount fsck authinfo contrib tips issues man/index resources impl_details ./usr/share/doc/s3ql/html/durability.html0000644000000000000000000004620312377424557017302 0ustar rootroot Important Rules to Avoid Losing Data — S3QL 1.11.1 documentation