Default steam folder exclusion too large

[Saroumane]

I discovered an hidden setting that prevents my whole steam folder from being saved ( ~/.steam/root )
It is indeed a good idea to save space, because a part of steam folder is already synchronized with Valve servers. But only a part !
Not all settings or game saves are on Valve servers. Some are only stored on local HDD.

In fact I think the only steam folder that should be excluded is this one (see provided screenshot for explanation) :
 ~/.steam/steam/steamapps
(It contains all games binaries)
=> 1/ Is it possible to make this change ?

As a workaround I tried (with déjà-dup settings) to override ~/.steam/root by explicitly listing it in "Folders to save".
It doesn't work !
=> 2/ Is it possible to allow this kind of manual override ?

Description: Ubuntu 15.10
deja-dup 34.0-1ubuntu3
duplicity 0.7.02-1ubuntu1

[Saroumane (saroumane)]

As deja-dup project seems more or less inactive, and can't be used as a reliable backup for steam users, I suggest everyone affected to use "Back in time". With this software :
- backup settings can be changed
- backup operation eats a lot less CPU, adn is faster (for me)
- data is easy to access, you don't even need the backup software

[Michael Terry (mterry)]

This one is tricky because steamapps isn't the only content in that directory that we don't care about. ubuntu12_32 is 1.1G on my system.

That whole directory is a mix of local user data and downloaded package data. With no documentation.

I'm inclined to leave the situation alone for now. But if someone can propose a way to deal with that directly intelligently & automatically, I'm all ears.

[Saroumane (saroumane)]

Hello, it's nice to see a reply, even after 3 years !

I explained a simple workaround in the bug description :
"As a workaround I tried (with déjà-dup settings) to override ~/.steam/root by explicitly listing it in "Folders to save".
It doesn't work !
=> 2/ Is it possible to allow this kind of manual override ?"
To put it simply : let the user have the "final cut" about what to backup. Don't hide default exclusions.

I understand you don't want to code it, fine.

But if you care a bit about ubuntu users (as far as I know, deja-dup is still ubuntu official backup tool), you should put a BIG warning (somewhere it can't be missed : in deja-dup settings ?) saying :

"This software is NOT recommended for steam users. It will NEVER backup your steam data, including save files"

[Vej (vej)]

We might want this in the proposed new UI as one of the default options.

Call it "Steam directory" and set the default to "off". If users want to include it, they can switch it to "on".

[Serrano Pereira (serrano-pereira)]

I was unpleasantly surprised by this feature today, when I tried to restore my home directory. I'd like to second #5. I think that would be a good solution.

[mokrates (mmolle)]

I find it absolutely crucial for the users to at least be informed about this. If they're not, my opinion is, this is a critical bug which renders this software partially malicious. (no joke).

If you're not informed that *some* arbitrary but unknown data (namely `.steam/...`, but user doesn't know this, because he's not told so, and which user is to say that `.steam` is the only thing or keeps being the only thing) is excluded from the backup, then this software doesn't provide ANY data safety for the user.

Multiple users reported being unpleasantly surprised and dismayed by a "Backup Software" they were using (and making an effort by providing a backup volume and computer time for it to run) not backupping data, they *explicitly* wanted being backed up.

In Short: This software is intended for people to use to have peace of mind about the safety of their data. This is no minor issue. It is a *trust* issue: We can't trust deja-dup to backup that which we do not want to lose. Therefore it doesn't provide peace of mind but does the exact opposite: Is my data safe? Idk! The devs arbitrarily decide if my data is important! And they can do so with every update of the software!

[Michael Terry (mterry)]

Let's review where we are in 2024:

- There is *some* feedback to the user that the folder is excluded. The Folders preferences page has a question mark that you can click for a list of all the default exclusions (including ~/.steam/root). Whether or not that is sufficient is open for interpretation, sure.

- You can work around this default exclusion by adding ~/.steam/root to the include list. (the OP bug reporter said that didn't work - maybe that was true at the time, but it works today)

For those reasons, I don't agree that this is a critical failure. But maybe I don't understand the issue well enough!

Let me explain the thinking behind the exclusion: The Steam folder is full of a lot of data that is actually a big local cache. All the game data can be redownloaded. Game saves are usually stored in the cloud. On my (non-gaming) laptop, I already have 25GB of data in the steam folder. I can't imagine how much would be there if I actually seriously gamed on this thing. I think I would also get plenty of complaints if I included the steam folder by default.

As Vej mentioned, there were/are thoughts around a redesign of the folder preferences UI, and if we do that in a way that makes it easier to toggle this exclusion off, I'm open to that. Depending on the answers to the below question.

So help me understand - what stuff in the steam folder is not cache but actual local-only content? Games that don't use cloud saving? Global steam (i.e. non-game) settings?

I wish there was a way to distinguish between files that are cloud-backed and those that aren't.

The best solution is probably the UI redesign that makes it easier to control big exclude options like that: https://wiki.gnome.org/Apps/DejaDup/Design/Review-2019-11#Preferences

But even doing that, it's kind of a crappy choice to make for users - like they may not know whether their game saves are cloud backed or not. And even if they do know, it would be nice if they could just back those up and not all the other junk.

Anyway, I've not yet prioritized the redesign, but maybe I should.