sense of data/updater-*****/backups after successful upgrade?

[devnull4242]

Because of discussion
https://help.nextcloud.com/t/was-kann-ich-mit-dem-automatisch-erstellten-backup-anfangen (sorry german)

there was the question what is the sense of data/updater-*****/backups after successful upgrade.
Is it needed? Is it a backup? We think there is no way back to an old software version.

The normal backup and restore strategy also differs from this backup:
https://docs.nextcloud.com/server/latest/admin_manual/maintenance/backup.html
https://docs.nextcloud.com/server/latest/admin_manual/maintenance/restore.html

We think data/updater- ***** /backups is only useful while upgrade.
issue:
Perhaps after successful upgrade data/updater- ***** /backups can automatically be deleted.
This saves a lot of space on nextcloud installations.

[Samonitari]

Hi,

firstly, thanks for your work! I'd also like this issue to be "fixed".

I almost bit the bullet - to be fair, it was partially my mistake - with a failed upgrade.

• Web updater clearly has a step saying backup -> so I did not create one before proceeding, my mistake
• After upgrading failed (my mistake, ownership of some to-be deleted files was incorrect) I found out latest admin manual clearly states that updater doesn't do backups! - I should have read this beforehand, I know, not just after the upgrade failed, and I wanted to locate the backup mentioned by the web-updater step.
• The truth is somewhere in between. Nextcloud app folder is backed up, data folder and database (seems to be) aren't

Now, this half-backup did save my arse.
I could fix the failed and stuck upgrade by restoring the app folder. After that php occ upgrade said I already had the latest version (info from database?), but web-updater was kind enough to run again (which inconsistency could be an issue in itself, btw). Of course I fixed the files/folders ownership before the second update attempt 😅
However it was mostly luck, as database was not changed too much during the upgrade, and the web updater clearly thought differently (about what version I have) than the command line updater.

Either:

• nuke "backup" process from the web-updater
• hide backup step in web-updater, or clarify that this step - contrary to what it in very clear English says - is not a backup. Also, clean up this half-backup from time-to-time, at least on next upgrade.
• make updater do a proper backup (that would be the most ergonomic I think)

[GregorKopka]

Also the updater should remove the backup it made after the update had completed without error.
Currently they pile up without ever being cleaned, eating space on the webserver and in the backups.

[uwe347]

I also have some gigabytes in my /updater-xxxxxxxx which blows up my backups and so i would like to get rid of it. But I wont dare do delete or omit it, as long as there is a risk, that my (incomplete) backup doesn't work.
Can anybody please answer this question?

[GregorKopka]

I also have some gigabytes in my /updater-xxxxxxxx which blows up my backups and so i would like to get rid of it. But I wont dare do delete or omit it, as long as there is a risk, that my (incomplete) backup doesn't work.

Make sure your backups work, then you can nuke the updater backups without endangering your nights rest...

[joshtrichards]

Perhaps after successful upgrade data/updater- ***** /backups can automatically be deleted.

There is a background job in server (nextcloud/server#9855) that handles backup clean-ups. It cleans any updater backups beyond the most recent three. It gets triggered:

• when triggering the Updater (here: https://github.com/nextcloud/server/blob/f99b820cd0e59b75bc8867a03dabc9e28157ccdf/lib/private/Updater.php#L302)
• when running an occ maintenance:repair

Is it needed? Is it a backup? We think there is no way back to an old software version.

The original goal, in part, was establish the groundwork for an automated rollback of an Updater run (see #52). A similar means of rolling back the db upgrades (i.e. what occ upgrade does after the Updater finishes) would need to be implemented to support what most would consider a true rollback. The latter currently doesn't exist.

EDIT: To clarify, it's safe to manually delete the updater created backups, as noted by @GregorKopka. Also, if you really don't want the updater backups to be created at all, there is an option --no-backup (if you use the command-line updater you can use this option).

[joshtrichards]

I could fix the failed and stuck upgrade by restoring the app folder. After that php occ upgrade said I already had the latest version (info from database?), but web-updater was kind enough to run again (which inconsistency could be an issue in itself, btw).

@Samonitari There is no inconsistency here between the web and command-line modes of the Updater. The command line mode of the Updater is "updatar.phar" not "occ upgrade".

@devnull4242 I'm going to close this out since I think it was answered at this point and there already is a clean-up job. In addition, there's no harm in manually removing the contents of the directory more aggressively after a "deemed successful" upgrade has taken place. If you or someone is seeing their updater backups not automatically cleaned up, feel free to log that as a bug in a dedicated Issue with the details of the environment/etc.