Source and Destination are reversed in main user interface.
Short Answer: All non-standard resources are standardized on the right in SyncBack. In some profile setups when required, data is set to flow from right to left to achieve the profile objective.
You may find with certain profile configurations that the device/service you are backing up from appears as the Right/Destination (and where you are copying to appears as the Left/Source)
This is quite normal (if a little unexpected, till you know why): anything that is not a standard disk or network resource uses a plug-in, and the socket for the plug-in/s is (only) on the 'right-hand-side' of the code. This is because 'way back when', your Source was almost always the standard disk/network resource (where your routine data was stored); it was always the Destination - if anything - that was required to be something different/off-system, e.g, FTP.
Slowly, it became more prevalent that users might wish to back up from such non-standard resources (e.g, back up a remote web-site via FTP download to a local device). Unfortunately, to accommodate this as a turnkey solution would have needed a ground-up redesign / rewrite so that both sides of the code had a 'socket' for the plug-in, which would have been a tremendous amount of work (all the more so as & when other extra features were added). So the 'lateral-thinking' solution of keeping the non-standard device/service on the traditional 'side' and reversing the data flow was adopted, and it persists to this day. It is highly unlikely to change.
So, when you select a profile type to back up from such a non-standard resource, we have to re-wire the profile, so that it maintains this orientation (non-standard resource is on the right) but data is then set to flow from right to left, to enable what you want to achieve.
If you create the profile from the New Profile wizard, it will do this for you automatically, and swap/rename the Labels that state (inside the Modify view) which side is connected to what, and the orientation of the display.
We can do this inside the Modify view (because we are only displaying one profile, so we can change things around). But when displaying all profiles (such as in the main UI), we have to apply one set of rules to all profiles, so such a profile will display the FTP (etc.) side as Right/Destination and your local disk or LAN path as Left/Source (because inside the code, that is true: the local disk (etc.) is indeed on the left of the code, but the data is correctly flowing to it, not from it). If you Modify the profile and check the Description pane on the Simple page that opens by default, it will correctly display the actions the profile will perform.
Note also that the icon in the Type column has the arrow (direction) reversed, showing it is copying Right to Left.
Bear in mind that other 'side-specific' aspects in the main UI may 'follow' this reversal - for example, right-clicking such a profile > Open Left/Source will open the standard resource listed under the Left/Source column (your hard disk or standard network location). And so on.
This affects all profiles configured to copy from
- SyncBack Touch
- FTP (all versions of SyncBack)
and in SyncBackPro only
- Cloud services
- Email Servers (backing-up files stored as attachments to emails)
- Email Servers (backing up 'normal' emails to local resources; note that this mode cannot in fact be configured so data flows in the local > remote direction anyway)
- Location scripts
(Raw optical burning is also always on the Right, but as an optical burner is always the Destination anyway, 'reversal' is not the case here.)
Note that this also affects profiles designed to synchronize between local resources (where data is intended to flow in both directions, if appropriate/possible). Regardless of whether you try (in the New Profile wizard) to set the non-standard ('uses a plug-in') resource to Left or Right, it will always appear on the Right.
This is also the reason why (in any version) you cannot have a profile that copies stuff from one non-standard resource to another (e.g. Cloud <> FTP, FTP <> FTP and so on). It is also the reason why you cannot use Compression on the standard-resource side of a profile if you are using a non-standard resource on the other - Compression also uses a plug-in, and there is only one side equipped with 'sockets', so you cannot have (for example) FTP files backed up to Compressed copies thereof on local disk.