With all these depressing threads about dying N900s, lack of Nokia stock to replace them, bulk buyers on eBay and the lack of credible N900 replacement devices in the market, I've decided that I will be using the N900 for at least another year, more likely two or three years until a whole new generation of devices is upon us.

I've just taken the plunge and bought myself a spare N900 off eBay, with a credible one month usage history, box and accessories, all for the sum of £135 delivered. Cheaper than insurance, cheaper than a new contract for a handset I probably didn't want, and if it means I can go SIM-free when the current contract is up, it'll pay for itself pretty darn quick. So now the question is how best to achieve (and then to automate) "bare-metal" redundancy against loss or failure of my primary phone; I'd like to know what others are already doing about this and whether there is a preferred approach. I'm broadly familiar with backupmenu, rsync, rdiff-backup, and so on and won't have problems backing up the FAT partitions over rsync or similar.

What I'd really like to be able to do is to fully automate a proper rootfs + optfs backup, like backupmenu takes, on a regular basis, without my having to actually boot into backupmenu and do so manually on a daily or weekly basis. Is there some way of doing a backup run at boot time, either from an initrd before the rootfs gets mounted, or with rootfs mounted read-only? Or is there a way of making it part of the shutdown process, perhaps by loading a rescue OS into RAM, chrooting to it and taking the backups from there?

If I can do either of the above, and ensure that the backup happens only if the phone is on charge, I can schedule a nightly reboot of the phone to dump the rootfs + optfs backup onto the microSD card, THEN take an incremental backup of something that actually might let me restore the phone. Does anyone already do something like this?

pretty sure that cant be done. Im with you though, my finacee "upgraded" to an E7 and I kept her N900 so I have a spare which I use to test.

I'm pretty sure it hasn't been done, at least in the mainstream, but I can't see a good reason why it can't be done. Unless someone can tell me where the showstopper is, I'm tempted to have a go. I can see the limitations; we need to work during startup or shutdown, with our filesystems not mounted, and that limits what we can detect about the state of the phone, filesystems, backups, etc. Can anyone see a problem in the following:

1) Start with backupmenu and automate it, such that when booted with keyboard open, it asks no questions, takes a backup and reboots. This would initially cause a reboot-backup-reboot loop unless and until the keyboard is shut.

2) Add some kind of check into bootmenu.sh to break that loop, so that we only launch the automated backupmenu under a predetermined set of conditions. Since we can't mount up the filesystem and check whether we just took a backup, can we check if the time is between 0400 and 0402 in the morning? If it is, run our automated backupmenu, if it isn't then boot into maemo.

3) Automate a reboot at 0400 daily provided that we're on charge. Assuming I've left the keyboard open, /sbin/preinit launches bootmenu.sh, which launches the autobackupmenu based on the time of day. This takes a backup to the microSD card and then reboots, whereupon preinit or bootmenu.sh decides that it's gone 0402, so go ahead and reboot maemo.

4) Automate the business of cleaning up the old backups and rsync the lot over to a PC nightly.

Admittedly, it hasn't been done yet that I know of, which causes me to wonder if I'm missing something, but is there any reason that can't work?

I think the easiest/simplest way is to just use rsync for the backup (that can be automated easily). I know it isn't good practise to run a backup on a live system since files can change during the backup, but if nothing is running at the time, it shouldn't cause an issue.

I have myself used rsync to clone one N900 to another and it didn't have any issues, though I haven't incorporated it into a regular backup strategy.

The only thing you have to watch out for is if you are restoring to a clean N900 you need to install the kernel (or a kernel if you have multiple installed) that was installed on the device when the backup was run.

I'm pleased to confirm that what I proposed above (automating what BackupMenu does) is possible, without too much reinventing the wheel.

So far, I've made a bastardised copy of the core script of BackupMenu which does exactly the same as if I ran BM in the usual way and pressed B for backup, T for both, S twice to put both on the SD card, wait for it to happen and auto-reboot when finished. That would cause a reboot/backup loop unless the user closes the keyboard, so I've added a check into /sbin/preinit - if there's a file called /nobootmenu, don't run bootmenu.sh and proceed with Maemo boot as normal, even if the keyboard is open.

That's a long way from finished, but it's enough to show me that this is conceptually possible; all I need to do is create /nobootmenu when we run our automated backup, and remove it again when we successfully boot back into Maemo. Add a way of swapping between the original BackupMenu as written and my bastardised version (currently being done via symlinks), and it will be possible to do something that sets up BM to run an automated backup, reboots the system loading the bastardised BM, which sets the don't-do-this-again flag and takes the backup, then reboots. Post-reboot, we use that flag to avoid running bootmenu.sh and so we boot back into Maemo, where we delete that flag. I've yet to perfect this, but, watch this space. Much credit is due to Robbiethe1st for such a nice clear bit of code, too.

I'll post back when I've fully figured out how to automate this, it's definitely nowhere near fit for public consumption just yet, but I'm having fun...