Michael Higgins wrote:
So, in setting up a huge repository of junk, I mean, important
business documents, I nearly ran out of disk space on rootfs. Much of
it was living in /var, like half the disk's worth.
I'd just dropped a new disk in for /home... to move some Outlook
files to IMAP & maildir folders. Had I been thinking ahead, I would
have partitioned it for /var as well, but I didn't.
So, I rsyncd /var to /home/varlink, moved /var to /oldvar, 'soft'
linked /var to /home/varlink/var and restarted some services that
were less than happy with the change, like the mail servers, mysql.
Everything seems to work now.
Now, was that a stupid thing to do, or should everything under /var
continue to work still, without issues?
I've done it that way and don't remember running into any issues. I also
did the "shut all services down, rsync var to somewhere, change mounts,
sync it back" trick without taking the machine down. No long term issues
with that other than having to rebuild the qmail queue at the time.
qmail is weird and inodes are tied into the queue mechanism so that was
expected. Modern MTAs shouldn't have the issue. Mysql Innodb can be a
bit odd if you move the database around, but as long as nothing changes
relative the mysql datadir it will also be fine.
You might want to check your Mysql install and purge bin logs if you
haven't lately. That tends to be the silent /var filler-upper in many
systems.
expire_logs_days = 7 is your friend.
kashani
