More of Michael's Not So Quick Tips

Migration

I migrated my filesystems to ext4 (I’ve come from an all0ext3 F10 to F11 upgrade, FWIW) and just like to mention that if you’re migrating your root filesystem you might want to regenerate your initrd via mkinitrd; the stock one I had didn’t seem to like ext4 (complained about unsupported filesystem options at boot time and failed dismally) but a quick initrd rebuild in rescue mode had me up and running in minutes.

I didn’t see this mentioned anywhere – perhaps I’m a corner case – but I thought I’d record it for posterity in case someone else finds it useful – or desperately needs it!

Backup

If you’re looking for a simple, cron-capable no-fuss delta/differential backup solution (looks over in Peter Gordon’s direction) I’d consider the “rdiff-backup” package, which has been in Fedora for quite some time, does rsync-like backups of reversed diffs – the actual data transfer is small, you can do “point in the past” backups with little fuss plus if you want just the last copy, you can just grab it from the backup tree as-is, without a need to invoke rdiff-backup’s restore (rdiff-backup -r) option. All you need is SSH set up between two hosts, ideally pubkey auth or GSSAPI (ie passwordless or pre-authenticated)

To back up a home dir (~fred) to a remote server, barney:

rdiff-backup /home/fred barney::/home/fred.backup

To restore tmp/wilma from last week (7 days)

rdiff-backup -r 7D barney::/home/fred.backup/tmp/wilma /home/fred/tmp/wilma

How simple is that?

Hacks for database admins

This is an ugly idea, but it’s functional and insanely simple:

Much of my day-to-day systems admin work is with web developers and frameworks. Some frameworks in my experience, whilst being insanely great and powerful for a developer have an unfortunate tendency to hide things under the hood – one example is where the framework defines the database schema (via ORM et. al) but keeps it fairly opaque to the developer – leaving it to the DBA / system admin to work out what may have changed.

This can be a PITA for both developer and systems mangler alike – the developer isn’t always sure if it’s introducing a regression and the DBA/sysadmin wondering about the performance difference.

Both PostgreSQL (pg_dump -s  or –schema) and MySQL (mysqldump -d or –no-data) allow you to save schema-only dumps of databases (I’m not sure about Firebird or others, I’ve not tried them out lately)

I take this at regular intervals and check it in to version control – I can then see changes via standard VC diff commands. It’s a simple hack but it’s functional and requires no extra tools.

This came about because I need to maintain a script that purges old data from a pgsql database, including foreign keys (manually as the schema doesn’t grok DELETE CASCADE) and a change in the FK relations means that my script broke – if I can follow the schema changes it becomes trivial to add in the FK changes needed. ?