Full backup – de­f­i­n­i­tion of a full backup

A full backup is at the core of any backup method. There are many other types of backups, but all of them require the initial complete backup to work as intended. Creating a full backup is straight­for­ward, though in­ef­fi­cient in the long run. Read on to find out more about full backups as part of our series of articles on backup strate­gies.

A full backup, also known as a complete backup, creates an exact copy of an entire dataset. Since a full data backup refers to a defined dataset, it is a relative term. The dataset from which a backup is created can include:

• all data on a laptop
• all payrolls of one year
• the entire root directory of a website.

So what is the dif­fer­ence between a full backup and a normal copy? First, a backup is usually created on a different physical medium than the one that contains the original data set. For example, one copies the data from the internal laptop SSD to an external hard drive. Fur­ther­more, a backup is an exact copy, which is why the process of creating a backup is also called “cloning” or “mirroring”.

It should be possible to faith­ful­ly re­con­struct the original state from a full backup. The purpose of a full backup is to create re­dun­dan­cy and to store the resulting copies in a dis­trib­uted manner in order to minimize data loss.

To create a copy in digital systems, data must be trans­ferred. The data is read from the source and written to the target. Depending on the size of the data set and the data line used, a complete backup can take a very long time.

To create a full backup, data is copied to physical storage such as an external hard drive or USB stick, or uploaded to cloud storage. Depending on the operating system and re­quire­ments, spe­cial­ized software is used for this purpose. However, often existing “on-board” tools in an operating system are suf­fi­cient. Below are a few examples of commands that can be used to create a full data backup using the command line.

To backup of a directory on the command line, we use the Linux copy command. We copy the source directory to a des­ti­na­tion path. The des­ti­na­tion can be on any volume mounted on the system:

With the -a option (“Archive”) the copy command creates an exact copy: time­stamps, access rights, etc. of target data are set to the exact values of the cor­re­spond­ing sources. This is critical, among other things, for systems that include code, such as WordPress. If the copy is created without using the archive option, there is a risk of security vul­ner­a­bil­i­ties or loss of func­tion­al­i­ty.

A widely used method for creating a complete backup is to create a tarball archive. To do this, we use the Linux-tar command (the name stands for “Tape Archive”) to create a single file from multiple files or di­rec­to­ries. For this to work, the target file must be specified as the first parameter:

The -z option instructs the tar command to use Gzip com­pres­sion. The resulting .tar.gz file is usually a factor of 2 to 10 smaller than the total size of the data included in the backup.

Rsync is a so­phis­ti­cat­ed software for copying data sets. The source and des­ti­na­tion can be located on the same physical system or on remote systems connected via the network. In case of the latter, Rsync uses the mature SSH protocol, among others.

Server backups with Rsync are created or restored in this way. For large data sets, it is ad­van­ta­geous that Rsync is able to resume aborted backups. Let’s look at the simplest example for creating an exact directory copy:

As with the cp command, the -a option for “archive” is used to create an exact copy. Our example assumes the directory to be copied does not yet exist on the specified path. If the directory already exists on the source, Rsync in­tel­li­gent­ly transfers only the changes as of the last copy operation. In this case, it is no longer defined as a full backup, but a dif­fer­en­tial backup.

The cp and Rsync commands are Linux tools. They are also available under Windows via WSL2 (“Windows Subsystem for Linux”). With Robocopy, a Windows-specific al­ter­na­tive is available. This is par­tic­u­lar­ly useful because the NTFS file system used under Windows has some special features.

Similar to its Linux coun­ter­part, Robocopy Backup is used from the command line. Besides an obvious con­nec­tion to RoboCop, the name of the tool stands for “Robust File Copy”. Let’s look at an example Robocopy command. We mirror a source directory to a des­ti­na­tion path:

The /mir option stands for “mirror”. Robocopy creates a complete backup of the source directory. Des­ti­na­tion and source are located on the local system or a Windows share connected via the network. Unlike Rsync, Robocopy does not support copying via SSH con­nec­tion.

To backup on Mac or Windows 10, you can use the system-in­te­grat­ed tools Time Machine or Windows Backup. With both tools a complete backup is created the first time they are run. In sub­se­quent backups, only the changes as of the last backup are trans­ferred. The system can be com­plete­ly restored from the full backup.

The tools presented so far use a local or remote operating system to write the target data. But what happens when you want to store data in the cloud for backing up? You could use a service like Cloud Backup from IONOS to this end. This protects your business data optimally against data loss and other issues like ran­somware en­cryp­tion.

Depending on usage, it can make more or less sense to create a complete backup of a data set. Other spe­cial­ized backup methods exist. Let’s look at the ad­van­tages and dis­ad­van­tages of a complete backup.

There are three main ad­van­tages to creating a full backup:

1. Easy to set up: onboard tools are enough
2. Most reliable backup method: low risk of data loss
3. Easy to restore: reversing the copy process is usually enough

One advantage of a complete backup is that it is rel­a­tive­ly easy to create. As a rule, you do not need any spe­cial­ized software, but can use existing on-board tools. Because a full backup includes the entire data stock, the creation does not require any special prepa­ra­tions. Only two re­quire­ments must be met:

1. There is enough memory available on the target system.
2. There is suf­fi­cient bandwidth to complete the copying process in an ac­cept­able amount of time.

Once you ensured that both re­quire­ments are met, you begin the backup process. Then you have to wait. It can take a while for a full backup to complete. Once copying is completed, you should check that the backup was fully done and without errors.

Another big advantage of a full backup is re­li­a­bil­i­ty. Since a complete backup includes the entire data set to be backed up, it is im­pos­si­ble to forget or overlook data. However, for this to happen, it is important to stick to the original intention: a full backup, by de­f­i­n­i­tion, means that the entire data stock is backed up.

Es­pe­cial­ly with large amounts of data, it may be tempting to find arguments to exclude certain data from the backup: “We don’t need that anyway”, “it was all backed up last time”, etc. Un­for­tu­nate­ly, this could lead to data loss. If no current backup of the excluded data exists, the damage is done. Therefore, it is necessary to back up the entire database even if it may take a long time.

Creating a backup is only half the battle. A backup is only valuable as long as it can be restored true to the original. Here, too, the full backup is the simplest: to restore data, only the backup itself is needed; it is usually suf­fi­cient to swap the source and des­ti­na­tion and run the copy process again.

However, with full backups, as with all backup methods, you should not assume that the original data can be restored from the backup without testing it first. Testing restores from backups are part of any solid backup strategy. Under no cir­cum­stances do you want to realize that the carefully created backups are worthless only when data loss occurs.

The main dis­ad­van­tage of a full backup is in­ef­fi­cien­cy. Creating a full data backup takes a long time and tends to take up a lot of space on the target medium. This is because a full backup, by de­f­i­n­i­tion, backs up the entire data set.

Mac users will be familiar with this issue from using the native backup software Time Machine. The first backup can take hours, or even an entire night depending on the amount of data to be backed up. This is because a complete backup of all data on the Mac is created during the first run.

First of all, creating a full backup is the basis for sub­se­quent dif­fer­en­tial or in­cre­men­tal backups. So without a full backup there is nothing as part of a backup strategy. In addition, there are a few cir­cum­stances that require or favor the creation of a full backup. Let’s take a look at a few examples.

Sometimes it may be unclear which com­po­nents of a data set are important. In this case, it is ad­van­ta­geous to back up fully first. With this safety net in place, the data can be viewed and sorted into cat­e­gories such as “bin it” and “keep it”. If any errors occur, the pre­vi­ous­ly created full backup can be accessed.

A similar situation emerges when changes to a system are made. Web ad­min­is­tra­tors will be familiar with the following: a new customer has an existing system that was pre­vi­ous­ly main­tained by another admin. Now, a new admin is supposed to make changes. But what happens if something goes wrong? The new admin does not know the system, the old admin is no longer available. Here it’s ad­van­ta­geous to back up com­plete­ly first. If changes fail and damage the system, admins can fall back on the full backup. Again, it is important to test the restore before making the changes.

If you want to migrate a system, e.g. move a WordPress site from one server to another, you need a complete copy of the website data. In the case of WordPress, this includes at least the WordPress root directory and the WordPress database. To prepare for the migration, one creates a complete backup of the data and transfers it to the new server. There, the site is re­con­struct­ed from the backup. Once you have ensured that the site is running smoothly, it can go live. In most cases, the old system is left in place for a while so that it can be used in an emergency. It acts as a full backup, so to speak.

Sometimes it is necessary to reboot a system. Think, for example, of a laptop with hard disk errors, or a website with a re­in­stalled server. In these cases, the procedure is similar to that used for system migration: create a complete backup, set up the un­der­ly­ing hardware or software again, and then restore the backup.

However, there is a crucial dif­fer­ence to system migration: when restart­ing, the original system is lost. It is best to follow the 3-2-1-backup-rule and create at least two complete backups of the system in separate locations. You should also test the restore process before restart­ing.

When a project is completed, all important data must be archived for the future. In research and de­vel­op­ment projects, change-proof archiving is a basic re­quire­ment for the avail­abil­i­ty or re­pro­ducibil­i­ty of the results. In photo or film pro­duc­tion, large quan­ti­ties of unique raw data are generated. These also need to be archived. The simplest measure is to create a full backup as a tarball or ZIP archive and store it on redundant data storage.

Even web projects reach the end of their life at some point. Before taking a website offline, it is standard practice to create a final, complete backup. This allows the site to be re­con­struct­ed in the future if necessary. Since a website includes code in addition to static data, you must include the execution en­vi­ron­ment in the backup. For example, one creates an image based on a virtual machine or container. This ensures that the system can be started in the future with all its de­pen­den­cies.

You might be familiar with the following: an older computer shows in­creas­ing signs of failure. At first, the computer crashes oc­ca­sion­al­ly, then ever more fre­quent­ly, until it rarely starts up. Here you need to act fast to salvage what can be saved. If you can get the system to run stably again, you should create a complete backup as soon as possible. This might be the last chance to do so. Once the backup has been created, you can sort through the data.

A common scenario that prompts users to in­tu­itive­ly create full backups is when they are dealing with an important data set that is regularly updated. Consider a folder con­tain­ing a doctoral dis­ser­ta­tion in the editorial process. The folder may contain only a handful of documents that col­lec­tive­ly comprise a few megabytes. The doctoral student works on the documents every day and backs up any changes that occur by copying the entire folder to a USB flash drive in the evening. Although rel­a­tive­ly in­ef­fi­cient, this approach is widely used among less tech­ni­cal­ly savvy users because of its sim­plic­i­ty.