A good practice to follow is to perform various forms of redundancy. 4D provides many features that provide a safety net, but sometimes these features can only go so far. There are additional practices that can be followed to add additional safety nets. When thinking of backups in 4D, many only think of backing up the deployment database. However, developers should also consider making backups of the development copy of the database too.

Backups and Copies
Having a backup is one of the most important practices. However, there are various forms of backups. 4D itself provides a backup system that will backup the database on a set interval. The files can also be copied into a compressed package like a zip file manually. One of the practices that might be overlooked is making backups of the development structure. Before a change is implemented it is good to make a copy of the structure in it's stable state and work on a "working" copy. This will allow changes or issues to be reverted if needed.

For example, if a database is converted from 4D 14 to 4D 20 it will not be able to be reverted. If a copy was made beforehand, the converted database can simply be deleted and the copy can be restored.

Storage
Not only is having backups a good practice but maintaining them properly is also suggested. When a backup is created, the backups should not all remain on one form of storage. If the storage fails, these backups may become lost. All of the backups should not be stored on the same location as the working set and should be stored on a separate location or better yet, applying redundancy and maintaining copies in multiple locations.

With 4D's project mode structures, using a version control system will help streamline this process for the developing copy of the structure.