Ran a rm -rf * on ext4 backup disk to "reset", next backup seems way too small
-
Hi guys,
Would like a sanity check please. I was running out of disk space often lately on my ext4 hard disk for backups, and so today decided to go in and remove them all and basically start fresh.
I expected that the next rsync backup would then be longer and take a lot more space up since it's the "first one", but it only consumes about 2 GB of space which seems way too small when the emails are over 18 GB total alone.
I'd have expected the first backup to be about 20 GB, especially since it's rsync and not tarball. Am I missing something? Is something wrong with the backups after I removed all directories on the ext4 hard disk dedicated to backups?
-
@d19dotca Did you remove the snapshot directory as well? With the rsync format, that directory is not supposed to be touched because it acts like a cache of files already "uploaded". (For example, think of this directory residing on s3. Cloudron won't re-read this snapshot folder, it will assume it's there untouched since it last ran backup).
Anyway, since you did remove it, you have to remove the snapshot files under
/home/yellowtent/platformdata/backup/as well. That will make the backup system realize that there is nothing "uploaded" and start afresh. -
@d19dotca Did you remove the snapshot directory as well? With the rsync format, that directory is not supposed to be touched because it acts like a cache of files already "uploaded". (For example, think of this directory residing on s3. Cloudron won't re-read this snapshot folder, it will assume it's there untouched since it last ran backup).
Anyway, since you did remove it, you have to remove the snapshot files under
/home/yellowtent/platformdata/backup/as well. That will make the backup system realize that there is nothing "uploaded" and start afresh.@girish ah yes I did. That’ll be it then. I’m just out at the moment but will try this later tonight. Thanks for letting me know so quickly. I suggest we may want to add this to the documentation (unless it’s there and I missed it, lol). I can try to submit a pull request in git too for that to help out.
-
@d19dotca Did you remove the snapshot directory as well? With the rsync format, that directory is not supposed to be touched because it acts like a cache of files already "uploaded". (For example, think of this directory residing on s3. Cloudron won't re-read this snapshot folder, it will assume it's there untouched since it last ran backup).
Anyway, since you did remove it, you have to remove the snapshot files under
/home/yellowtent/platformdata/backup/as well. That will make the backup system realize that there is nothing "uploaded" and start afresh.@girish Okay perfect, this worked, thank you so much! Quick question though, I assume this is expected but it just surprised me so wanted to double-check... the files inside of the /home/yellowtent/platformdata/backup/ directory was mostly owned by root:root, is that correct? I assumed it'd mostly be owned by yellowtent:yellowtent, the only file I saw owned by that user and group was the snapshot-info.json file.
-
Those sync.cache files are state files of the rsync backup uploader. That has to run as root to be able to list and read the app's files, the app file permissions here depend on the app itself and how it manages permissions.
The yellowtent user as such does not have root rights on the system and uses helper scripts in such cases. The list of scripts which need and thus run with elevated permissions can be found at https://git.cloudron.io/cloudron/box/-/blob/master/setup/start/sudoers
