Storix Software SBAdmin User Guide - Manual (Page 35)

data, for any client type, may be encrypted using 128, 192, or 256-bit AES encryption. You may only select
this button for the number of clients your encryption license supports.
Enabling data encryption for a client does not cause all backups to be encrypted
automatically. It only designates which clients will support encryption. For clients
that support encryption, the encryption option becomes available when configuring
backup jobs .
To encrypt data for a client, each client must have at least one configured Encryption Key. The encryption
key must be a 32, 48 or 64-byte hexadecimal number, depending on the number of bits of encryption used.
An encryption key will be given a user-defined Encryption Key ID, and you may have as many Key IDs as
you like. You will later select which Key ID to use when performing a particular backup.
To prevent encryption keys from ever being transmitted across the network, the encryption keys may
not be configured from within the GUI interface, and client keys may not be configured from the
network admin system. Instead, you must run the stkeys command on each client for which encryption
is to be used. Refer to stkeys in the
Commands Reference Guide , and the Encrypt data field in the
backup job configuration for additional information.
Sparse File Handling
A sparse file is a file in which blocks of data have been written non-sequentially, leaving unallocated blocks
in the middle of a file. If the sparseness of a file is not preserved when restoring, the file will be expanded to
include all blocks in the middle of the file, often causing a filesystem to inadvertently run out of space.
Preserving sparseness in files is usually desirable and the default. This is sometimes a problem, however, if
your files were pre-allocated using NULL characters. If a file is created and all blocks are allocated by
writing nulls, or "0"s, throughout the file, the file appears identical to a sparse file on the backup. Since files
containing null blocks are indistinguishable from sparse files, the blocks are not retained upon restore. The
affect is that a file created at a large size could be restored to a very small size.
To resolve this issue, you may select the Preserve Sparse Files “No” option so that all backups of this
client will be created without preserving the sparseness of files. Therefore, if a file was pre-allocated using
NULL blocks, the null blocks will also be restored. Note that, when using this option, a truly sparse file
(created without pre-allocating blocks by writing nulls) will be interpreted a large file of null blocks, and will
be expanded upon restore in order to retain the null blocks. This will often cause the filesystem to run out of
space since a file that was once very small is restored quite large.
If a backup is created by preserving sparseness, which is the default, then the
backup files may not be restored to another system of a different operating system
type. If you want to restore a backup to a different operating system type, then you
should turn OFF sparse file handling BEFORE creating the backup.
Preserve File Access Times
When a file is backed up it is opened for reading and the access time in the inode table is updated. While
this does not affect the modification time, it does change the access time. To prevent this behavior, you
may select the Preserve File Access Time “Yes” option to retain the original access time during a backup.
This option is only valid for Linux and Solaris systems and is not available for AIX.
Storix System Backup Administrator 35 Version 8.2 User Guide