Plugin: Backup & Restore - Create compressed archive

[mrmanuel 6]

Please make it possible to create the backup as compressed archive, like *.tgz or *.zip. This makes is much easier to copy the backup to other places, without the need to copy hundred of files.

[Luke 42077]

Hi, yes that would be easier to copy although more difficult for the server to keep changes in sync with the backup.

[mrmanuel 6]

Would it be possible to add that as an option maybe, so the user can choose if the backup should be created compressed or uncompressed?

[Luke 42077]

It's certainly possible, yes.

[mrmanuel 6]

Is this the right place for such a feature request? Do I need to provide more information or is it enough to wait for upvotes or someone devices to integrate this?

[Luke 42077]

4 minutes ago, mrmanuel said:

Is this the right place for such a feature request? Do I need to provide more information or is it enough to wait for upvotes or someone devices to integrate this?

HI, yes this is the right place. No more info needed. Thanks.

[TDriver 53]

I hope this change will be implemented soon.

[Jrod696 28]

I was searching around for this same thing that this post is talking about, I understand the logistics of creating a compressed file with the versioning etc, however I am curious if there is a better way to just store the people data in a db or outside the increments or something like that.

The reason people data specifically is I have a 3-2-1 backup system and when the rsync runs its having to process 600 Thousand images and files each time and because the files are so small it takes quite a long time. I am not worried so much about reducing the size but the quantity of the files.

[Luke 42077]

1 minute ago, Jrod696 said:

I was searching around for this same thing that this post is talking about, I understand the logistics of creating a compressed file with the versioning etc, however I am curious if there is a better way to just store the people data in a db or outside the increments or something like that.

The reason people data specifically is I have a 3-2-1 backup system and when the rsync runs its having to process 600 Thousand images and files each time and because the files are so small it takes quite a long time. I am not worried so much about reducing the size but the quantity of the files.

Hi, what data are you referring to?

[Neminem 1518]

The backup from the Backup and restore plugin is not compressed.

Even a backup over LAN is taking a long time, 10.000's files being copied takes forever, when manually compressed it takes 5-10 min. 

Edited December 15, 2025 by Neminem

[Jrod696 28]

Yes and No, a 3-2-1 backup system is slightly different and yes my NAS is capable of ripping through the backup pretty quick except when you do a Hash comparison on the files.

But its the 1 in the 3-2-1 that things start to slow down significantly. especially in the range of the 100's of thousands of files, dont even really need to compress it just put it in a container, that would reduce time quite a bit.

 

Edited December 15, 2025 by Jrod696

[Jrod696 28]

29 minutes ago, Luke said:

Hi, what data are you referring to?

I am referring to the metadata folder in the Full Backup folder, its mostly the library and person folder that have massive amounts of small files

[Luke 42077]

Anything in there is already in the database, except for image files.

[Jrod696 28]

18 minutes ago, Luke said:

Anything in there is already in the database, except for image files.

A lot to unpack, the root folder of backups the database folders for incremental are relatively small and not much to them, the full backup folder is the big one, the library folder is full of jpg files for chapters and .fp files, the people folder has the images of the person and the nfo file for that person. but for each person its 1 folder and in that folder is 1 image and 1 .nfo.

[Luke 42077]

The info inside the nfo files is also in the database.

[Jrod696 28]

1 hour ago, Luke said:

The info inside the nfo files is also in the database.

I agree but that is a small portion compared to the 18gigs of images that are also being backed up, and yes I know I can technically turn that off but then there are no chapters or cached images of actors, and if you are recovering from a backup that's all the stuff that would be nice to have so you don't have to re-scrape and spend 30 hours rebuilding the library.

what if the chapters were kept in the series folders vs the Emby library folder, it wouldn't reduce the quantity in general but it would reduce the backup substantially which is the real issue, not sure just trying to think outside the box for alternatives.

That doesn't work for the people data though because then you would have so many copies for the same person.

I know images can be stored in a DB itself although that is a far more complicated endeavor but you could have a db for each Title so instead of a dozen chapter images you would have 1 DB file which could reduce the quantity substantially.

 

As I said I don't know there is a solution to this issue, let a lone a simple one I am just more or less thinking out loud at this point.

Edited December 15, 2025 by Jrod696

[bradford 9]

This topic has been discussed before, and I've chimed in before. Compressing and archiving the backup into a single file needs to be an option, if not the default behavior, especially when a single backup is hundreds of megabytes if not gigabytes on disk. Since the files are so small, they can take up much more disk space than their collective sizes because of sector size. If the file is 1KB, and a sector is 4KB, then you have a 4x increase in disk usage. If the backup solution requires they be uncompressed, then I'm afraid the backup solution needs to be reworked.