The system administrator should generally establish routine backup procedures for the whole system at each site. However, application programmers should be sufficiently aware of these procedures to understand what is backed up and how often. After considering the tradeoffs between saving time on daily backups and losing time on a complicated restore procedure, the administrator should develop a backup strategy that meets the system’s needs and file usage patterns. It should be noted that complex backup procedures can sometimes lead to data loss when inexperienced operators use them.
Given the ever – decreasing availability of backup times (known as the backup window) and the increasing time required to actually perform this backup, corporate IT was caught in a binding position. It could not guarantee that the system would run without up – to – date backups, but it could not even partially shut down the system so that it could actually do those backups.
To solve this dilemma, a number of strategies have been developed. Partial backups are the first. These depend on the existence of full backups at regular intervals, and the idea is to save time by saving only those files that have been changed, knowing that the other unchanged files are already backed up. The backup software looks at the modification date and time of each file on the system to determine which files have changed, and if the time stamp of a file is later than the last full backup, the file will be included in the next differential backup.