Re: QtMoko backup/restore
On Thu, 22 Nov 2012 19:59:30 + Neil Jerram wrote: [cut] > > My first stab at that is attached below. Comments welcome! Very nice and useful!! > > Radek, it's pretty alpha and incomplete, but would it perhaps be worth > committing already to the repository, so as to have something to build > from? > > Regards, > Neil > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
"dmatthews.org" writes: > Hi Neil > >> 1. it wants to mount and unmount the device (/media/card) where backups >> are stored, whereas QtMoko wants /media/card mounted the whole time > > That's not the case. You can configure it to backup to a directory on the > same device as the one you're backing up. > >> 2. it wants to use symbolic links on the backup device, which FAT >> doesn't support. >> > > You could make a ext2/3 partition on the card and have that mounted on > /media/card with a backup directory. > > Although I'm not wanting to do this myself, I've no doubt it's doable. I'm a > long term backup2l user - I fell in love with it after reimaging a foobarred > server and having everything back up exactly as it was within an hour. > > IMO backup2l is an unsung gem It is a very nice tool for its job, but I'm thinking now that that job is not exactly what we need for QtMoko, and that we'd be better off with a QtMoko-specific tool. - For QtMoko we only want a one-off, user-initiated full user data backup immediately prior to each upgrade. We don't need the automatic cron-based backing up and backup levels (i.e. full + incremental levels) that backup2l provides. - For QtMoko I think the restore operation, or at least some of it, ideally needs to happen immediately after unpacking the new rootfs, i.e. before the new QtMoko has had any chance to run. One might not even be running on Linux at that point. Therefore that step should be as minimal as possible - ideally just unpacking a tarball of user data. - We will probably want other not-just-backup operations for QtMoko, such as exporting contacts to a file and later reimporting them, or reinstalling additional packages in the upgraded system. Probably backup2l has hooks for these kinds of things, but I suspect it could become harder to maintain a combined backup2l + hook script system than just to write a QtMoko-specific script. My first stab at that is attached below. Comments welcome! Radek, it's pretty alpha and incomplete, but would it perhaps be worth committing already to the repository, so as to have something to build from? Regards, Neil >From 41eb4dc2912e7efc5aab16559a4bcb27d026c35b Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Sun, 18 Nov 2012 21:04:12 + Subject: [PATCH] Backing up settings before an upgrade - first stab --- src/module_essentials.pri |1 + src/settings/backup/backup.svg | 115 src/settings/backup/desktop/backup.desktop |9 +++ src/settings/backup/qbuild.pro | 15 src/settings/backup/scripts/backup.sh | 77 +++ 5 files changed, 217 insertions(+) create mode 100644 src/settings/backup/backup.svg create mode 100644 src/settings/backup/desktop/backup.desktop create mode 100644 src/settings/backup/qbuild.pro create mode 100755 src/settings/backup/scripts/backup.sh diff --git a/src/module_essentials.pri b/src/module_essentials.pri index 9eeb26e..71df725 100644 --- a/src/module_essentials.pri +++ b/src/module_essentials.pri @@ -5,6 +5,7 @@ PROJECTS*=\ 3rdparty/applications/qx \ 3rdparty/applications/screenshot \ 3rdparty/applications/qterminal \ +settings/backup \ settings/light-and-power \ settings/security \ applications/calculator \ diff --git a/src/settings/backup/backup.svg b/src/settings/backup/backup.svg new file mode 100644 index 000..f4ae7be --- /dev/null +++ b/src/settings/backup/backup.svg @@ -0,0 +1,115 @@ + + +http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"; [ + http://www.w3.org/2000/svg";> + http://www.w3.org/1999/xlink";> +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/settings/backup/desktop/backup.desktop b/src/settings/backup/desktop/backup.desktop new file mode 100644 index 000..ec0e437 --- /dev/null +++ b/src/settings/backup/desktop/backup.desktop @@ -0,0 +1,9 @@ +[Translation] +File=QtopiaApplications +Context=PowerManagerServices +[Desktop Entry] +Comment[]=Backup settings before an upgrade +Exec=backup.sh +Icon=backup/backup +Type=ConsoleApplication +Name[]=Backup Settings diff --git a/src/settings/backup/qbuild.pro b/src/settings/backup/qbuild.pro new file mode 100644 index 000..a361038 --- /dev/null +++ b/src/settings/backup/qbuild.pro @@ -0,0 +1,15 @@ +script.files=scripts/* +script.path=/bin +script.hint=script +INSTALLS+=script + +desktop.files+=desktop/backup.desktop + +desktop.path=/apps/Settings +desktop.hint=desktop +INSTALLS+=desktop + +pics.files=*.svg +pics.path=/pics/backup +pics.hint=pics +INSTALLS+=pics diff --git a/src/settings/backup/scripts/backup.sh b/src/settings/backup/scripts/backup.sh new
Re: QtMoko backup/restore
Hi Neil > 1. it wants to mount and unmount the device (/media/card) where backups > are stored, whereas QtMoko wants /media/card mounted the whole time That's not the case. You can configure it to backup to a directory on the same device as the one you're backing up. > 2. it wants to use symbolic links on the backup device, which FAT > doesn't support. > You could make a ext2/3 partition on the card and have that mounted on /media/card with a backup directory. Although I'm not wanting to do this myself, I've no doubt it's doable. I'm a long term backup2l user - I fell in love with it after reimaging a foobarred server and having everything back up exactly as it was within an hour. IMO backup2l is an unsung gem -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
Boudewijn writes: > Is it not FAT, so that it can be exported as "mass storage"? The rationale > being, that most host operating systems would have FAT drivers on board? > > > > I think that for many of us, the systems we connect to via USB already have > drivers for other file systems than FAT. > > > > Do you have an idea of the general area in the QtMoko sources, where there > might be a check on the FS type? I can try to have a look if I can get > anywhere > with some pointers. Or is there a mass storage standard, that does not allow > for other FS than FAT? I'm afraid I haven't yet looked into or thought about the question of why we use FAT for /media/card, or if FAT is really required. (I just followed the partitioning instructions that said FAT, but that was many moons ago and I can't even quickly find now where those instructions live.) I certainly agree with you that probably everyone in our community would be able to mount a non-FAT filesystem. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
On Sunday 18 November 2012 11:04:28 Neil Jerram wrote: > 2. it wants to use symbolic links on the backup device, which FAT > doesn't support. > > (1) feels fixable, but (2) feels tricky to work around. Is it not FAT, so that it can be exported as "mass storage"? The rationale being, that most host operating systems would have FAT drivers on board? I think that for many of us, the systems we connect to via USB already have drivers for other file systems than FAT. Do you have an idea of the general area in the QtMoko sources, where there might be a check on the FS type? I can try to have a look if I can get anywhere with some pointers. Or is there a mass storage standard, that does not allow for other FS than FAT? Best regards, Boudewijn signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
Neil Jerram writes: > backup2l looks pretty nice; thanks for the suggestion. Two problems though: 1. it wants to mount and unmount the device (/media/card) where backups are stored, whereas QtMoko wants /media/card mounted the whole time 2. it wants to use symbolic links on the backup device, which FAT doesn't support. (1) feels fixable, but (2) feels tricky to work around. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
"dmatthews.org" writes: > Hi Neil >> >> - It should be pretty quick and easy to write scripts to do this. A GUI >> would be nice, but that can come later. >> >> Thoughts? Does anyone already have such scripts? >> > > backup2l? > > The best documentation is here:- > > http://symbiosis.bytemark.co.uk/squeeze/docs/symbiosis.html#ch-backup-reference > > nb symbiosis is a debian based "easy hosting" system that includes backup2l; > since backup2l is basically a shell script it doesn't care what sort of linux > it's running on. There are debian paclages. backup2l looks pretty nice; thanks for the suggestion. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
Hi Neil > > - It should be pretty quick and easy to write scripts to do this. A GUI > would be nice, but that can come later. > > Thoughts? Does anyone already have such scripts? > backup2l? The best documentation is here:- http://symbiosis.bytemark.co.uk/squeeze/docs/symbiosis.html#ch-backup-reference nb symbiosis is a debian based "easy hosting" system that includes backup2l; since backup2l is basically a shell script it doesn't care what sort of linux it's running on. There are debian paclages. -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko backup/restore
On Saturday, November 17, 2012 02:46:05 PM Neil Jerram wrote: > I wonder if anyone is already thinking about or working on backup and > restore for QtMoko when upgrading - i.e. to maintain all your settings > and data across an upgrade? Yes i did :) > My thoughts so far on this: > > - Most non-system data lives in a separate partition, /media/card, and > doesn't need handling because an upgrade won't touch that partition. > > - For the same reason, /media/card is a good place for backing up > anything that does need handling. Yes, i aggree, /media/card is good location for backups. > - It should be pretty quick and easy to write scripts to do this. A GUI > would be nice, but that can come later. I would personally very like export of my contacts in vcf format to /media/card/Documents. It shouldnt be hard since qtmoko can send contacts via email attachement. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko backup/restore
I wonder if anyone is already thinking about or working on backup and restore for QtMoko when upgrading - i.e. to maintain all your settings and data across an upgrade? My thoughts so far on this: - Most non-system data lives in a separate partition, /media/card, and doesn't need handling because an upgrade won't touch that partition. - For the same reason, /media/card is a good place for backing up anything that does need handling. - Stuff that does need backup and restore is under /home/root: settings, email/SMS messages, spectemu ROMs, web browser stuff, and so on. Unfortunately this is a mixture of genuine user data and application-generated runtime state, and I think it would be better to let the new distribution regenerate the latter. So possibly that means that we can't just save and restore the whole of /home/root. But maybe the algorithm can be "save and restore the whole of /home/root except for a manageably small number of exceptions". - Maybe also backup and restore /etc/ssh/*key*, to avoid having to delete the old key on SSH clients? - It should be pretty quick and easy to write scripts to do this. A GUI would be nice, but that can come later. Thoughts? Does anyone already have such scripts? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
