search

ttionya / vaultwarden-backup

Backup vaultwarden (formerly known as bitwarden_rs) SQLite3/PostgreSQL/MySQL/MariaDB database by rclone. (Docker)
MIT License
956 stars 113 forks source link

backup size #115

Open michaelkallweitt opened 1 year ago

michaelkallweitt commented 1 year ago

I installed vaultwarden-backup from the docker-compose.yml, only making adaptions in the backup section:

19c19
<     environment:
---
>     # environment:
21c21
<        RCLONE_REMOTE_DIR: '/Apps/BitwardenBackup/'
---
>     #   RCLONE_REMOTE_DIR: '/BitwardenBackup/'
23,28c23,28
<        CRON: '5,10,15,20,25,30,35,40,45,50,55 * * * *'
<        ZIP_ENABLE: 'TRUE'
<        ZIP_PASSWORD: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
<        ZIP_TYPE: '7z'
<        BACKUP_FILE_SUFFIX: '%Y%m%d%H%M%S'
<        BACKUP_KEEP_DAYS: 7
---
>     #   CRON: '5 * * * *'
>     #   ZIP_ENABLE: 'TRUE'
>     #   ZIP_PASSWORD: 'WHEREISMYPASSWORD?'
>     #   ZIP_TYPE: 'zip'
>     #   BACKUP_FILE_SUFFIX: '%Y%m%d'
>     #   BACKUP_KEEP_DAYS: 0
35c35
<        TIMEZONE: 'Europe/Berlin'
---
>     #   TIMEZONE: 'UTC'

Backup seems to be working fine (at least it doesn't throw errors). However I was wondering about the size of the resulting backup file. Here's the ls of my original files (stored on the DSM):

ls -la /volume1/docker/vaultwarden/data
total 5828
drwxrwxrwx+ 6 michael users    4096 Jun  1 13:13 .
drwxrwxrwx+ 3 michael users    4096 Jun  1 13:22 ..
drwxrwxrwx+ 2 root    root     4096 Jun  1 13:13 attachments
-rwxrwxrwx+ 1 root    root  1769472 Jun  1 13:29 db.sqlite3
-rwxrwxrwx+ 1 root    root    32768 Jun  2 08:57 db.sqlite3-shm
-rwxrwxrwx+ 1 root    root  4132392 Jun  2 08:57 db.sqlite3-wal
drwxrwxrwx+ 2 root    root     4096 Jun  1 20:18 icon_cache
-rwxrwxrwx+ 1 root    root     1679 Jun  1 13:13 rsa_key.pem
-rwxrwxrwx+ 1 root    root      451 Jun  1 13:13 rsa_key.pub.pem
drwxrwxrwx+ 2 root    root     4096 Jun  1 13:13 sends
drwxrwxrwx+ 2 root    root     4096 Jun  1 13:13 tmp

And this is what I get from the backup (after unpacking the archive):

total 464
drwxr-xr-x    6 michael  staff     192  2 Jun 09:18 .
drwx------@ 275 michael  staff    8800  2 Jun 09:17 ..
-rw-r--r--    1 michael  staff    1536  2 Jun 09:05 attachments.20230602090502.tar
-rw-r--r--    1 michael  staff  221184  2 Jun 09:05 db.20230602090502.sqlite3
-rw-r--r--    1 michael  staff    4608  2 Jun 09:05 rsakey.20230602090502.tar
-rw-r--r--    1 michael  staff    1536  2 Jun 09:05 sends.20230602090502.tar

I am a little concerned if really all of my data are contained in the backup db. Maybe there is some overhead, but can this account for the different file size?

ttionya commented 1 year ago

No worries. The running database contains various elements such as indexes, caches, and optimizations to enhance its performance, which makes it larger than the exported content. On the other hand, the other directories are tar-packed, and the size you see with ls -l represents the directory size (which is typically 4096 in Linux) and not the size of the files within. You can use the du command to check the actual size of a directory.

If you are concerned, you can try restoring the backup files and compare them with the files before the backup. I believe that, apart from the database size difference (due to indexes, caches, etc.), the sizes of other files and directories should remain the same.