On 2018-04-18 04:25, f...@igh.de wrote:
Dear List,

running BackupPC v4 I sometimes ran out of i-nodes.

I have about twelve servers to backup with a total amount of about 2
TB and aboz 20 million files. I keep about 50 backups.

On an ext4 file system it is likely to run out of i-nodes rather than
to run out of disk space (this holds if the file system was created
using the default parameters). In my situation I have only used half
the space but almost all i-nodes available.

Because I prefer ext4 for it's robustness and reliability I have to
consider i-nodes.

We have the pool (or cpool) storing the actual files. And we have the
pc directory storing the structure. The most files in pc are small or
even empty, but they are many (in my case ten times more than the
actual files in pool). They waste an enourmous amount of disk
space.

So I created a separate (logical) partition of only 200 GB in size and
formatted with 1024 bytes per inode and per block (mkfs.ext4 -b 1024
-i 1024 ...). I later use it for pc.

Then I simply copied the pc entries (note: only the entries, not the
complete directory) to the new partition using cp -a. This took about
50 hours but worked correctly (this also shows, that BackupPC v4 can be
replicated). Afterwards I removed the entries from the original pc
directory and mounted the new partition there.

I started BackupPC once again and it works like a charm.

In this constellation remarkable space for the future backup space was
released. If I ever would run out of space or i-nodes again I will
simply increase either of the partitions.

As a suggestion I would recommend an information about i-nodes
consumption in the server status page.


Finally I am looking for a formula that could be used to estimate the
required disk space and i-nodes depending on the number  and size of
files and the number of backups kept.


Best regards


Torsten

I note that many people simply use modern file systems which employ dynamic inode allocation, and therefore, neither this feature, nor this type of analysis nor maintenance is necessary. Those who do reach back a decade or more to select a filesystem, I generally expect to have good reason and spend time performing analysis rather than using the defaults, though your mileage may vary. I'm not impugning your choice of ext4 as a matter of taste (nor your excellent work in solving the issue) I'm pointing out that information about inode consumption in the server status page would be pretty useless to a lot of people.

It's difficult to provide an exacting formula, naturally, but here's the general form:

backup size x ( number retained x rate of change ) / compression + overhead

Backup size and number retained are relatively easy to measure, typically, both in terms of number of files and data size. "Rate of change" is the tricky one, since it's the measure of how quickly your files churn. If this ratio is zero (i.e., your files don't change) then backups don't add much needed space. If they change a lot, you'll need a lot more space.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Reply via email to