That's not a problem in my thinking. If you backup a lot of small files, your file table will grow a lot. After your definied recycle time, old files will be deleted from the table.
If your "old" system has different backup rules or vm's the number of files is possible smaller and so the file table is smaller. This table is, from the numbers I can see, your biggest difference between old and new.
How long do you store backups before your overwrite the media files? Have you done tests and these test data is still in the new system?Have you compared backup jobs between old and new (number of backuped files)? Have you compared the job definitions, eventually you exclude some stuff in the old system? Same usage scenario of the vm's? We have a dev machine and a job creates a lot of temp and testfiles ... Do you backup the vm as file or do you backup the files from inside of the vm?
I would wait until the system gets to the point where it recycles volumes and look if you have a "stable" disk usage after this. A new system will grow at the beginning and your db size is not big. I mean 10G is nothing. Our backup system is small and the data dir is 20G in size.
Best Silvio Am 03.12.24 um 10:01 schrieb Ramil:
I got a little confused when I wrote the server name. I meant that the
database size of the old CT-BAREOS01 server, which is more than 2 years
old, is larger than the new VL-BAREOS02 (1 month of use). CT-BAREOS01
has much more VMs backups than VL-BAREOS02, but the database size is smaller
вторник, 3 декабря 2024 г. в 14:43:22 UTC+6, Silvio Schloeffel:
Hi Ramil,
you wrote your old server has more backup files (files to backup in my
mind).
The size of the file table says something different.
Have you done a simple count over the file table to look for the number
of entries?
Eventually you backuped more files as expected on the new system.
-> a lot of small files will not grow the used media size but the
filesize and the infos to store will be a lot more
Best
Silvio
Am 03.12.24 um 09:25 schrieb Ramil:
> pg_size_pretty(pg_total_relation_size(relid)) AS total_size
--
You received this message because you are subscribed to the Google
Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected] <mailto:bareos-
[email protected]>.
To view this discussion visit https://groups.google.com/d/msgid/bareos-
users/fab8132e-e880-484f-a5f3-d30dd175e718n%40googlegroups.com <https://
groups.google.com/d/msgid/bareos-users/fab8132e-e880-484f-a5f3-
d30dd175e718n%40googlegroups.com?utm_medium=email&utm_source=footer>.
-- Silvio Schloeffel | CIO [email protected] Tel. +49 3677 2094 840 the evolution of music continues MusicDNA GmbH Schwanitzstrasse 6, 98693 Ilmenau, Germany Phone: +49 3677 2094 840 | Fax: +49 322 298 222 00 Steuer-NR.: DE 156/114/04317 Handelsregisterzeichen: HRB Jena 517208, Geschäftsführer: Sebastian Schmidt www.musicdna.com -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bareos-users/d4c00ab8-a193-4f39-85bf-ca80e900fbdb%40musicdna.com.
OpenPGP_signature.asc
Description: OpenPGP digital signature
