There are many ways to achieve the goal of backing up data from a larger partition into a smaller partition using GParted or other tools.
To copy the partition into a smaller partition you might use the following sequence of steps in GParted: Shrink source partition, copy source partition to destination, grow source partiion back to original size. Note that there is always some risk involved in editing partitions.
To copy only the data (with no compression) from the source partition you might mount both the source and destination partitions and then copy the contents from the source to the smaller destination using command line tools or a graphical file manger.
To create a smaller backup of the data in a partition you might consider using a tool that compresses the data into a single file, such as FSArchiver. FSArchiver is included on the GParted Live image.
1) It takes much more time to shrink a partition and then subsequently expand it again than just to implement the GParted feature I suggest.
2) There may be data in a partition that needs to be copied in the exact same order as it exists in the source, such as bootup code in the very beginning of a partition. Doing what you suggest would fail miserably in such a scenario.
3) Compressing data and subsequently uncompressing data takes time, and does not guarantee that all the relevant data is being compressed.
Once again I appeal to you, or to GParted, to implement this simple feature that would make GParted much better functionality wise than it currently is. I am not trying to butter you up, but GParted is a very good program. But the inability to have it allow the copying of the data portion of a parttition to another area whose size is equal to or greater than just that data size, would make it much better. Am I really the only person who uses GParted that finds it incredibly irritating that if I have a very large size partition whose data consists of something well less than the total size I must copy it to a partition area that is equal to or greater than the size of the source partition rather than to an area that is equal to or greater than the size of the data in that partition ? Why shoud I have to waste a tremendous amount of hard disk space in that way, or got through a slow subsequent process of shrinking down my destination partition, when Gparted should be able to do it with the feature I suggest in a single quicker step. Why is this suggestion seen as being so technically outrageous when GParted already is showing me that it has all the information it needs to do this and, in fact, appears to correctly copy only the data anyway into the destination partition to begin with. In other words I do not see that GParted has to do any extra coding than it already does do, but simply just needs to allow the end-user to choose in its GUI a destination partition that is big enough for the data area of the source partition rather than the entire size of the source partition. Is there anything else that GParted actually has to do ? Is this being held back by the underlying Parted code ? Your resistance to even considering this basic improvement to GParted suggest some other difficulty other than just changing the GUI front end code to allow it, so I am really curious as a programmer what is behind that resistance. Do you actually not see how this feature would make GParted much more useful for end-users ?