After enabling AD authentication on a server you might end up with a « huge » /var/log/lastlog file that in my case did not played nice with my BackupPC with rsync xfer method: it resulted in a 300 GB lastlog file!
The reason is that this /var/log/lastlog file is a « pre-allocated database » file that stores the login activity for all the users UIDs on the server, and being connected to a Samba AD DC, I now have users with UIDs well above 1 billion! This « pre-allocation » uses the sparse feature and allows to have a 300 GB file allocated using only 28 KB of real disk space:
# ls -lh /var/log/lastlog
-rw-rw-r-- 1 root utmp 279G oct. 31 12:35 /var/log/lastlog
# ls -sh /var/log/lastlog
28K /var/log/lastlogHandy feature. However, when you start backuping a host like this, you might end up with disk-usage problems when all your backup chain is not « sparse-aware » and is not able to treat sparse files efficiently.
This showed up with BackupPC using the rsync transfer method, when dumping this new host blew up my disk space.
The problem here is that the BackupPC’s rsync transfer do not handle sparse file « efficiently » resulting in effectively retrieving and storing 300 GB of data before compressing it to its cpool.
Warning : do not try to add the --sparse flags to the rsync transfer method as the BackupPC’s rsync receiver is not compatible with it or you might end up with corrupted files in your backup.
So, the only safe solution for the moment is to exclude the /var/log/lastlog from backup.
P.S.: here is a quick one-liner to detect sparse files, ordered by increasing ratio of real-data-size / total-sparse-size (lower means a huge sparse file with few data in it):
find / -type f -printf "%S\t%h/%f\n" 2>/dev/null | grep -v '^0[[:space:]]' | sort -k1g | head