Before implementing Novell Archive and Version Services in your network environment, collect information about your system to assess your versioning needs. Ask and answer the following questions:
Users: Which users would benefit from having an archived database of multiple historical versions of their network files? For example, in a university environment, you might provide versioning support for faculty and staff, but not for campus lab environments.
Examine business and operational activities to identify and prioritize users’ versioning needs. Use this information to plan a strategic implementation of versioning throughout your network.
Volumes and Directories: What volumes do these users use? How are the user directories organized on each volume?
If you are versioning only selected users’ data on a volume, you can exclude all data, and then include each user’s data by path.
If you archive files from an encrypted volume, the destination path for Archive Manager should also be on an encrypted volume. If the destination path is a nonencrypted volume, the versioned data is stored in a nonencrypted state.
For any source volume, you can define only one versioning job. If you attempt to define multiple jobs for a volume on the same or different server, Archive and Version Services does not run as designed and data integrity in the archive database is compromised.
The archive server can be the same or different server as the source server.
A single archive server can archive many volumes with only one job defined per volume.
A given volume cannot have multiple jobs defined for it, even if the jobs run on different archive servers.
Files and directories that reside under Distributed File Service (DFS) junctions are not versioned, because Archive and Version Services does not support junctions. If you need to archive data that resides on the target volume of that junction, set up jobs on the target volume and server pointed by that junction.
File Extensions: What types of data within these volumes are candidates for versioning? For example, productivity files such as documents, spreadsheets, presentations, graphics, and other file types typical in your industry.
Many types of data do not need versioning and can quickly consume valuable space in your archive database. Avoid versioning system files, log files, and databases. In addition, do not version temporary files that have no value to users, such as temporary Internet files and temporary application files. Identify the extensions of temporary files to be excluded from the job.
Archive and Version Services fails to create versions for iFolder or any other application that creates backup files.
Versioning Frequency: How often does the identified data change on each volume? You should set the frequency to best satisfy the needs of the users. Look for patterns in frequency, such as the following:
Does frequency vary by types of data?
Does frequency vary by individual users?
Does frequency vary by categories of user, such as power users, support groups, or manufacturing?
Does frequency vary by physical location? For example, headquarters, branch offices, geographical regions, or departments.
Does frequency vary by time? For example, by time of day, day of the week, week in the month, month in the year, fiscal quarter, season (winter, spring, summer, or fall), or special events.
Storage: What are the minimum initial storage capacity and scalability needs for your archive database? Determine this information by assessing your current storage requirements. For example:
How much storage space is consumed by each data type? For example, estimate the number of files and their average size.
What is the expected growth of data? For example, the additional number of megabytes or gigabytes of storage needed by users by month, quarter, or year.
What is the rate of growth in storage capacity by data type? For example, evaluate the percentage increase over time of a particular file type, such as documents, spreadsheets, presentations, graphics, or other file types typical of your industry.
Archive Database: The potential size of the archive database depends on the combination of the following:
How many versioning jobs are defined for the server?
How often does each job run?
How many files are versioned on the source volume?
How often are the files modified and how does that correspond to the scheduled interval for the versioning epoch?
What is the delete policy for the job?
Topology: Where in the enterprise network are the volumes stored? For example, a data center, a branch office, or work islands throughout the campus.
Delete Policy: What type of retention policy for file versions do you need for each volume? Establishing a delete policy helps you control the storage capacity required by the archive database. For example:
How long do you need to retain versions?
What is the maximum number of versions to keep, given the number of source files versioned and their sizes?
Do you need to keep at least one file version after its source file has been deleted?
Do you need a complete copy of all the data to begin the archive database, or do you want the collection of file versions to grow only as data changes?