Deciding how to refactor a class having many methods - language-agnostic

Question

I have noticed that my classes tend to be larger/longer compared to code I tend to read online. The code below is intended as an example, but I am more interested in the way to think about and how to approach the problem.
As you will see the class handles many roles and I would love to learn on how to refactor it into other classes and examples, if possible, on practical solutions. Links to books/guides on how to solve this problem would be great.
So I have a Backend class with the following declaration. I am using C#, but I think that my question covers other languages.
public static class Backend {
//These classes are the equivalent classes of a cloud database tables
//Using them to map the tables to objects in my app
public class User{}
public class Place{}
public class SubPriority{}
public class Question{}
public class Parent{}
public class Response{}
public class SubParent{}
//initialize the local and cloud databases
public static async void init();
//Add place to local database
public static string AddPlace(string name, string buildingType)
//Retrieve places from local database
public static List<Place> RetrievePlaces()
//Delete a place from local database
public static bool DeletePlace(string placeID)
public static string AddSubPriority(String name)
public static List<SubPriority> RetrieveSubPriorities()
public static bool DeleteSubPriority(string placeID, int ID)
//Sync local db with cloud
public static async Task<bool> SyncWithCloud()
//Download SubParents from the cloud
public static async Task<List<SubParent>> DownloadSubParents()
//Retrieve SubParents from local
public static List<SubParent> RetrieveSubParents(int parentid)
...
...
...
//Similar methods for parents and questions
//Handling login
public static async Task<bool> Login(string userName, string pass)
static async Task<bool> LoginOnline(string userName, string pass)
static bool LoginOffline(string userName, string pass)
//Check for internet connectivity
static async Task<bool> isConnectedToInternet()
static bool InternetAvailable()
}

Answer 1

Separation of Concerns
The difficulty with keeping all of this logic in one class is that changing one thing is likely to require significant changes to the whole class, which will create bugs. And equally importantly, it's easier to read and understand when classes assume a single role. Code that is readable always has fewer bugs (in my experience).
Your single class is handling at least the following roles:
Maintaining a collection of objects (your "local database")
Reading from/writing to a cloud server
Converting cloud server data to your model class objects
Keeping the local database in sync with the cloud database, in both directions.
Defining your business object models (User, Place, Subpriority etc).
Coordinating all of the above.
If I were implementing this, I'd break 1-4 out into separate classes. For #5, I'd move the models outside of Backend, so they're standalone classes.
Maintaining a collection of objects (your "local database")
Data storage belongs in its own class. With all of your object types, this is already pretty complex.
Reading from/writing to a cloud server
Any code that accesses an external resource belongs in its own class, which does only data access. Ideally this class should be defined first as an interface, and callers should call it only through the interface. This makes it easier to swap providers, and also aids in testing (you can supply a different DAL implementation at runtime for tests) and reinforces separation of concerns.
Converting cloud server data to your model class objects
This can be done in the DAL, or in an intermediate layer. For downloading cloud data, you could add methods to your collection classes like
LocalDatabase.Users.Update(List<User> usersFromCloud){}
Keeping the local database in sync with the cloud database, in both directions.
An intermediate class sitting between Backend, the cloud DAL, and the local database could sync "automatically" whenever it knows the data on one side is stale. Alternatively, this could be moved to a utility class. Which is best depends on your requirements.
Defining your business object models (User, Place, Subpriority etc).
Code outside of the backend is using these models, so they belong outside the backend definition.
Coordinating all of the above.
When you take out everything listed above, what's left will be a bunch of method calls to the new classes to do all the work. Your Backend class will become more of a coordinator that delegates work to the appropriate class.
Other things I'd do differently
Use non-static classes. If you are going to use one global object to provide access to the backend, you can use a singleton. (Google "C# singleton" for examples.). This will make it easier to test your code (by swapping out what you store in the singleton, e.g. with a dummy implementation that returns values from a text file) and easier to switch to a non-global implementation later if that becomes necessary.