Backup Boot Disk
In order to backup the whole boot disk you have to configure FoldersSynchronizer as following. Since FS has to copy system's files and maybe even other users' files, the logged user needs to own the root's privileges. Also, since the destination disk must contains an exact copy of the source boot disk, you have to set FS to execute an Exact Backup.

Repair the boot disk permissions
Before running any backup of the boot disk, we strongly suggest, to repair your boot disk permissions by executing this command line on the Terminal:

sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

Root privileges
In order to execute the backup of the boot disk, since it contains system’s files and maybe even other users' files, you need to login to your machine as the root user. The root user is a special super user who can do everything (copy, replace, delete, change ownership, change permissions) on all the files placed on local volumes. He can do everything even on system’s files and other users' files. In order to get the root’s privileges you can: When you logged in your computer as user "root", FS will display the pathnames of the source and destination folders blue-out, so you will always know whether you are backing-up with the root’s privileges (see the picture aside). When FS runs as root it can copy/replace/delete all the files, included the system’s files and all the other user's files. When FS runs as root it can copy the ownership and permissions to the destination files. These two points are fundamental for backing up the boot disk.

Enable the root user (if never done earlier)
When you install macOS and configure your machine for the first time, the user "root" is not yet enabled, so you cannot log-in as user "root" nor FS can run as root. So, if you never enabled the user root on your machine, you have to do that right now. If you already have done this, you can skip this chapter and go to the next one. In order to enable the "root" user please do the following: To know more please consult this page at the Apple web site:

Configure FoldersSynchronizer to backup the boot disk
In order to configure FS to perform a backup of your boot disk you have to:

Backup the boot disk to a local volume
You can backup your boot disk to a local internal disk or a local external disk just plugged in your local machine like a Fire-Wire or an USB disk. Since you are backing up system files you have to preserve the files' ownership and permissions. In order to preserve the Ownership and Permissions of all the files (system's files included), the destination disk must be set to recognize the file ownership and permissions. To do that, please: Then define in FS, as destination, the root of the destination disk (drag the disk icon onto the bottom zone of the FS console). If you backup your boot disk to a simple folder placed on the destination disk, the destination disk will be not be bootable.

Backup the boot disk to a remote volume
More than the rules described at the previous chapters (you have to go to the remote machine and unmark the check-box "Ignore Ownership on this volume" - the destination volume must not be an active boot volume, the disk should be formatted as MacOS X... see the previous chapter), you have to pay attention to some rule more regarding the privileges on files. When you backup your boot volume to a remote volume (a volume placed on a remote machine) you might get some problem because you need to run with the root's privileges (in order to preserve the files' ownership and permissions), but there is a MacOS X limit on the user root in front of the remote volumes. Even if you logged in on your local computer as user root, or you run FS as root, you and FS will never get the root's privileges on remote volumes. The remote volumes don't trust the local root user. Thus in front of a remote volume, the local user root becomes the "Others" user (and just something more). So the user root gets the Others' privileges, and not the root's privileges. Thus you, and FS, will not be able to copy system's files.
There is a workaround for this problem: you should mount the remote volume as FireWire volume.