How to backup your Amahi

[gboudreau]

I'd like to document & create an easy to run procedure to backup Amahi, in case I need to reinstall it later on.
For example, if/when my / partitions becomes corrupted or something.

I'd like to get back the exact server I have now, which means:
- My Amahi settings: everything I have in my Amahi dashboard. For example: shares, advanced settings enabled?, static IPs, aliases, storage pool configuration, etc.
- My installed Amahi apps, including their data (most of the time, their database) & config files.
- My custom web-apps: I created a couple of web-apps using Apps > Webapps > Create. I don't want to loose those!
- My installed software: apps I installed using yum.

To achieve this, I'd need to back up:
1. Directories:

Code: Select all

/etc/ /var/hda/web-apps/ /var/hda/platform/html/config/

2. Lists:
- Installed RPMs
- Installed amahi apps
3. Complete MySQL dump
4. All config files from installed RPMs. Maybe we can identify if they were modified or not, and only backup if they were?
5. The iso I used to install, in case it's not available anymore when I need to reinstall.

Procedure to restore:
- Re-install Amahi, using the same install code (profile)
- Restore /var/hda/platform/html/config/
- Re-install all amahi apps (can we do this from the command line?)
- Restore /var/hda/web-apps/
- Re-install all RPMs; (in two passes, since the first try could install repos that are needed to find some RPMs.)
if any RPMs are not found, warn the user, and tell him he should manually download and install them.
- Restore RPMs config files
- Restore /etc/
- mount -a
- Restore MySQL database
- hdactl-hup (I guess it does stuff relative to the MySQL data we just inserted... right cpg?)
- (TODO) Need to identify ruby code that needs to be called here; for example, the code that generates smb.conf and restart the smb service, and the code that generates greyhole.conf, and restarts the greyhole service.
Maybe it would be easier to make a fake HTTP session on the dashboard, during which we'd change some values to trigger the above code (change a share path, change options in the storage pool page, change a static IP, etc.
- Reboot ?

Anything I'm forgetting ?

[whetu]

Would a full live/atomic snapshot work instead? Trying to automate it all is admirable, but I think you'll find it fast becomes a maintenance nightmare

To do a full live snapshot, I use this followed by dd (to an .img file) on a couple of critical redhat boxes, along with a separate database dump which then rsync off to a pair of high-availability backup servers colo'd in another city, as well as to HDD's which are off-sited locally. We also do selective-data rsync incrementals to a local server and the remote colo boxes.

The full restore process is to boot up to a live environment and dd the latest .img back, then rsync back any subsequent incrementals. You could even dd | scp the img, or dd | gzip | scp, or use sshfs or any other way to restore the img over the network.

Because it's an atomic snapshot, when you boot into the restored system, the database should just work straight off the bat, but we still keep a seperate db backup just in case. We treat recovering from a snapshot like recovering from a power outage: most of the time it's fine, but you never know...

[toothandnail]

I would wonder if all application data would be picked up that way. I've wiped it and will have to reinstall it, but I think WebERP was placing its data in /var, but not with the rest of the hda data.

I have a somewhat similar situation - I maintain a number of SME servers for small business. To back them up, the best option is a clean reinstall, followed by a restore from backup. I've been using Synbak to do the backups - it has very good include/exclude options, can write to a number of different types of media (I've got it writing to local hard drives and also to NAS shares, as well as using rsync for some backups). Its also ideal set up as a cron job, so its fully automated.

There's an rpm version which as been tested on Red Hat and Fedora (and works on CentOS, which is what SME is based on). Home page is here:

http://www.i-synapse.it/portal/it/produ ... k/overview

For use with SME, I have to dump the MySQL databases before starting the backup, but that is the only prerequisite. And I've done several resores using the backups created.

Paul.

[gboudreau]

You guys talk about the how and where to. I'm talking about the what, which I think comes first.
Once we identified 'what' needs to be backed up, then we can choose how to do the backup, and where to (which would probably be a user preference anyway).

I don't want to daily (hourly?) create a full backup of my whole HDA!
So I need to find all the dirs / files that needs to be monitored for changes, in order to include them in the incremental part of the backup, when they do change.

Also, this procedure should allow me to re-create the HDA I had, but on other hardware.
Say I'm running on i386 now, and my CPU breaks for whatever reason, and I decide to buy a new one, but a x86_64 this time. I want to be able to get back my HDA... I just upgraded the CPU!
Full metal backups won't help in those cases.

What I want, is to find all the data that needs to be moved over to the new server, to get back what I had (minus the home/shares data - that should be backed up with CrashPlan or whatever, if you care about it.)

[moredruid]

gboudreau,

Linux is very forgiving in it's hardware support. I've even migrated a disk image from a VMWare install to a hardware rig without much hassle. As long as you don't have exotic hardware RAID controllers that break you should be fine and you'll only run into issues when you're going from x86 to a different architecture (VIA/Arm/Sparc/RISC/S390/Itanium - anyone has one those last 4 at home???).

My first endeavour into this field was when the PSU in one of my old servers burned out. It was a Celeron 300MHz Intel chipset system with a 3com NIC and the burnout took the mobo and CPU with it. The drive was luckily unaffected and I succesfully put it in another system: AMD 64 with Via chipset and onboard NIC - everything worked as it should. This was with Debian Woody. Those days are long gone and hardware support has only become better.

That said, I do think it's important to think this through.
I'm currently in a somewhat same situation: migrate Amahi, the apps etc. and the database to the new system or dd my OS disk over to a live-disk booted system and stay on F11.

This is why I would prefer a more long term distro for those averse to change
Fedora moves too fast to be a steady target (from the Fedora page: The Fedora Project releases a new version of Fedora approximately every 6 months and provides updated packages (maintenance) to these releases for approximately 13 months. This allows users to "skip a release" while still being able to always have a system that is still receiving updates.)

For a home server this is way too fast. Upstream packages break (quite often due to fast development), wreaking havoc in Amahi. If you choose CentOS 5 as base you have a very stable, dependable and predictable platform. You can go as fast with the Amahi development as you like since you can trust the foundation.

I hope that with the release of CentOS 6 Amahi will port a long-term support release to that platform. If not I might even be tempted to go back and build my own serverconfig. Convenience is a secondary concern for me, stability and dependability is king as I use my hda as a small business server for my gf's DTP company.

[whetu]

You guys talk about the how and where to. I'm talking about the what, which I think comes first.

Well, I was talking about a full live snapshot... which kind of means everything. So the what was inherently covered

So I need to find all the dirs / files that needs to be monitored for changes, in order to include them in the incremental part of the backup, when they do change.

The approach that I picked up at a previous job, when I was under the wing of a long time UNIX hacker, was that instead of whitelisting what you think you want, you should instead blacklist what you know you don't need. The argument being that when you come to restore, it's better to have everything available should you need it, rather than to find out that you forgot to add some important dir to your whitelist.

We'd found that with most incrementals, that outside /tmp and the databases (and in this case home/shares data) most changes on a day-to-day is mostly just log activity. And every once in a while other things would change - we'd update a script or install some lib or something. So we'd just run system wide incrementals as they tended to be quite small. We'd obviously do things like exclude database datadirs as we'd handle those separately with the full backups and the database backups.

Towards the end of my time there, we came across and started using hcp, and we had a relatively basic script that would mount a hotcopy, and then run something like e.g:

Code: Select all

find /var/hotcopy/sda1 -type f -mmin -1440 -wholename '/proc' -prune \ -o -wholename '/some/oracle/data' -prune \ -o -wholename '/some/other/exclusion' \ 2>/dev/null | xargs tar -rzf /mnt/backups/`date +%Y%m%d`-backup.tgz

(note, that's an example off the top of my head so it's probably got a couple of errors)

This would find all files changed in the last 1440 minutes (i.e. 1 day, you could use -mtime -1) and then tar them up with a datestamped tgz. The tgz would then get scp'd off. The script would go on to send us an email report showing the output of the scp and an ls -lah /mnt/backups | sort -nr | head -n 10, which would show us the last 10 backups and their sizes. That would give us at-a-glance trending i.e. If a backup jumped significantly in size over the previous, we could investigate. The script also re-ran the find and piped it out into a datestamped txt file, so for our investigation we could simply diff with the previous.

Before using hotcopy, we used trickery along the lines of:

Code: Select all

#prepare for tomorrow's run touch -t /tmp/`date +%Y%m%d`-stamp.txt yesterday = /tmp/`date -d "1 day" +%Y%m%d`-stamp.txt find / -newer $yesterday | xargs tar -rzf /mnt/backups/`date +%Y%m%d`-backup.tgz

Of course the script was a bit more in depth than that, but it would fail on open/locked files where the hotcopy version didn't.

MySQL backups were handled by AutoMySQLBackup, which I wholly recommend. Postgres was just a pg_dump script, Oracle was likewise similarly scripted.

Also, this procedure should allow me to re-create the HDA I had, but on other hardware.
Say I'm running on i386 now, and my CPU breaks for whatever reason, and I decide to buy a new one, but a x86_64 this time. I want to be able to get back my HDA... I just upgraded the CPU!
Full metal backups won't help in those cases.

i386 will run fine on x86_64 It's when you go the other way, or to some completely different architecture like ARM or SPARC that you'll have trouble. See Moredruid's post. The advantage here with having a full snapshot is that you've already got everything. Just reinstall Amahi, mount your snapshot .img and copy out what you need. This is where your approach can help, and this is probably a good start:

http://www.cyberciti.biz/tips/linux-get ... store.html

/edit: Building on the above, and doing it your way, you'd probably want to refer to this thread as a configuration backup and restore. I think for that you could just generate a nice xml file that had the install code (which itself would look after a bunch of settings), the above installed software, a list of installed apps etc. You want the output of a theoretical hda-config-backup to be as small as possible; a tgz or zip with a couple of files in it. The hda-config-restore process unzips this file and greps out what's required. Having a seperate database dump should be considered useful but not mandatory IMHO.

If that's what you meant, then I like it, and apologise for going off on a tangent

[hfl]

This is a good discussion. For a non-expert user, it would be good if the Amahi development team makes available from the Amahi dasboard a function for Export and for Import. As part of the integration of an application, scripts should be added that cover the export/import of that application's data. As a cherry on the cake you'd allow to tick ON/OFF whether a application is included in the export/import.

That would be great - thank you very much for consideration somewhere in the roadmap.

fl

[bigfoot65]

Hello,

Great idea. Please submit a feature request at http://bugs.amahi.org. We will add it to the list of improvements for Amahi.

[sgtfoo]

Backing up a complete amahi/F12 config is incredibly useful now. I may need to re-install F12 and change the SATA ports for my drives around a little.
If I swap motherboards, would everything work just as fine?

-what needs to be backed up to retain the users/share settings/customizations I currently have?
(cuz re-entering lines and lines of commands to get my media server happy, took me a while.

-can greyhole partitions just lie dormant until the re-install is done?

..heh yea I'm new at this.

[tarl]

Great idea. Please submit a feature request at http://bugs.amahi.org. We will add it to the list of improvements for Amahi.

There are similar ideas already submitted:
http://bugs.amahi.org/issues/show/592
http://bugs.amahi.org/issues/show/212