Ubuntu System Restore

John Moser john.r.moser at gmail.com
Sun Oct 30 20:57:51 UTC 2011


The simple way to create a restore point system ...

... is to mount / as an overlay FS, which you periodically merge (to
remove prior restore points), condense into a squashfs (to take a
point backup), or wipe (to restore to backup).  This of course means
/home should be its own partition.

On Sun, Oct 30, 2011 at 4:40 PM, Bear Giles <bgiles at coyotesong.com> wrote:
> You need to either have a local repository or download from the internet
> again. I've used 'apt-mirror' in the past to maintain a local cache but that
> was when I was building local systems with a minimal Debian installer. I
> don't even know if the standard Ubuntu installer can load off a local cache.
> (I guess the process is to do the install "without updates", change your
> sources.list files, then upgrade from the cache.)
>
> It's also worth remembering that the specific versions of your packages may
> not be available when you need to restore your system. This is usually a
> good thing since more recent versions have a shot at preventing whatever
> caused you to lose your system in the first place (e.g., closing
> vulnerabilities) but some people may need to restore the system exactly.
> On checksums - I checked my system and almost none of the conffiles have
> checksums. (In fact that may be against packaging standards - I would have
> to check.) That's a bummer since it means that there's no easy way of seeing
> what's changed unless you peek into the .deb file. There are some deb tools
> that can do this but since I can do it programmatically I usually just did
> that.
> The 'monster diff' is just a comment on the number of files involved. What I
> actually did create two lists, one generated by walking the filesystem and
> the other generated by concatenating all of the *.files and *.md5sums
> metadata and then comparing them. I did this programmatically but you could
> also create actual files, sort them, and then run a diff on them. IIRC I
> typically had over 70k files.
> On Fri, Oct 28, 2011 at 3:33 AM, Gaurav Saxena <grvsaxena419 at gmail.com>
> wrote:
>>
>> Hello all
>>
>> On Fri, Oct 7, 2011 at 4:45 AM, Bear Giles <bgiles at coyotesong.com> wrote:
>>>
>>> I've written a few prototypes and this comes down to four issues. Some of
>>> the details below are debian/ubuntu-specific but the same concepts will
>>> apply to redhat.
>>>
>>> 1. User data (/home) must be backed up explicitly. (ditto server data on
>>> servers).
>>> 2. Packages should NOT be backed up. All you need is the package name and
>>> version. Reinstall from .deb and .rpm if necessary since this way you're
>>> sure that you never restore compromised files.
>>
>> But it might be possible that the package files are not available on the
>> system. That means for all the packages installed the .deb files need to be
>> downloaded from the internet for restore purpose ?
>>>
>>> 3. Configuration data (/etc) must be backed up explicitly. This is tricky
>>> because backing up the entire directory will cause its own problems. Worse,
>>> some applications keep their configuration files elsewhere. The best
>>> solution I've found is to scan the package metadata to identify
>>> configuration files and to only save those with a different checksum than
>>> the standard file.
>>
>> Ok. Nice idea indeed , but is there checksum associated with the files in
>> the package ? Or that can be calculated at the time of restore ? What you
>> say ?
>>
>>>
>>> 4. Local files. Ideally everyone would keep these files under /usr/local
>>> and /opt but that's rarely the case. The best solution I've found is to scan
>>> the debian package metadata and do a monster diff between what's on the
>>> filesystem under /bin, /sbin, /usr and (chunks of) /var with what's in the
>>> metadata.
>>
>> Could you suggest me some way of scanning the debian package metadata
>> without actually downloading the packages? and how to this monster diff ?
>>>
>>> It's worth noting that the last item isn't that hard if you have a strict
>>> security policy that everything under those directories MUST be in a
>>> package. It's deleted without a second thought if it's not. You can still do
>>> everything you could before, you just need to create a local package for it.
>>> So what do you do with this? The best solution, which I haven't
>>> implemented yet, is to handle #2 and #3 with autogenerated packages. You set
>>> up one or more local packages that will install the right software and then
>>> overwrite the configuration files. You can fit everything, including
>>> original package archive, on a single DVD.
>>
>> Could you please tell some detail about autogenerated packages ? Like if
>> we have a list of packages installed on the system, We need to reinstall
>> those all softwares  and remove those which are installed after the restore
>> point?
>>>
>>> BTW Debian has a C++ interface to the package metadata. I've never used
>>> it - I find it easier to just scan the metadata directory myself. There's
>>> also hooks that will allow your application to be called at each step during
>>> a package installation or removal. You could, in theory, keep your snapshots
>>> current to the last minute that way.
>>
>> So whenever a package is installed or removed I will update my backup
>> according to that ? By reading package metadata determine which files are
>> changed by that package and update those files in the backup ?
>>>
>>> On Fri, Sep 30, 2011 at 12:01 AM, Gaurav Saxena <grvsaxena419 at gmail.com>
>>> wrote:
>>>>
>>>> Hello Aaron
>>>> Thanks a lot for your quick reply.
>>>>
>>>> On Fri, Sep 30, 2011 at 10:03 AM, Aaron C. de Bruyn <aaron at heyaaron.com>
>>>> wrote:
>>>>>
>>>>> In Windows, the ability to snapshot is built into the filesystem.
>>>>> In Linux, you must be running a filesystem that supports snapshots.  I
>>>>> know LVM supports snapshotting and I believe BRTFS has support, but
>>>>> other than that I'm not sure.
>>>>>
>>>> Yes I read the logic behind windows system restore. But I think we can
>>>> take some other approach for this, that will be better as all users won't be
>>>> able to spare an extra partition formatted brtfs.
>>>>
>>>>>
>>>>> Basically, your program would have to check the file system that is
>>>>> used on the computer (remember Linux can have many types of file
>>>>> systems mounted at the same time), then (in the case of LVM) make sure
>>>>> there's enough free space to snapshot, and finally take the snapshot.
>>>>>
>>>> Ok. Do I have to snapshot the whole system partition / important system
>>>> files to the brtfs partition ?
>>>>
>>>>>
>>>>> When the snapshots start filling up, you would either need to delete
>>>>> them or detect the low space and resize them.
>>>>>
>>>>> In my personal opinion, snapshotting in Linux is currently a pain in
>>>>> the rear.  It sounds like BTRFS could change that, but it's still a
>>>>> ways off.
>>>>>
>>>> Ok.  I will try another approach that will be better as suggested by
>>>> people here.
>>>>
>>>>>
>>>>> -A
>>>>>
>>>>> On Thu, Sep 29, 2011 at 21:00, Gaurav Saxena <grvsaxena419 at gmail.com>
>>>>> wrote:
>>>>> > Hello all,
>>>>> > I want to write a windows system restore like program for ubuntu ,
>>>>> > which
>>>>> > will have options for creating restore points for the system and then
>>>>> > restoring it back to that point. Also I will as an extension provide
>>>>> > support
>>>>> > for older version of a file as is in windows currently. I need your
>>>>> > help to
>>>>> > find how to start with this in ubuntu. I know that I have to snapshot
>>>>> > the
>>>>> > system when creating a restore point and then restore it. I need some
>>>>> > starting pointers so that I can start doing this work. Also if this
>>>>> > has
>>>>> > already been done please inform me. I got this idea from
>>>>> >  https://wiki.ubuntu.com/SystemRestore.
>>>>> > --
>>>>> > Thanks and Regards ,
>>>>> > Gaurav
>>>>> >
>>>>> > --
>>>>> > Ubuntu-devel-discuss mailing list
>>>>> > Ubuntu-devel-discuss at lists.ubuntu.com
>>>>> > Modify settings or unsubscribe at:
>>>>> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>>>>> >
>>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks and Regards ,
>>>> Gaurav
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks and Regards ,
>>>> Gaurav
>>>>
>>>> --
>>>> Ubuntu-devel-discuss mailing list
>>>> Ubuntu-devel-discuss at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>>>>
>>>
>>
>>
>>
>> --
>> Thanks and Regards ,
>> Gaurav
>
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
>




More information about the Ubuntu-devel-discuss mailing list