Ubuntu System Restore

Mon Oct 31 21:36:54 UTC 2011

Going back slightly you can specify a script/program that will be run by
dpkg at key points when packages are installed and removed. I never went
beyond logging the parameters to a log but I remember at one point you get
the location of the .deb file being installed. You could grab information
from it at that time.

(My idle thought was wondering how much effort it would be to have an
add-on that would set the 'immutable' flag on all non-conffile files as
they're written, then removing the flag before they're deleted. This is for
a mixture of oops-proofing and making life a little harder for attackers.
It wouldn't slow down a knowledgeable attacker.)

Bear

On Mon, Oct 31, 2011 at 11:32 AM, Gaurav Saxena <grvsaxena419 at gmail.com>wrote:

> Hello John,
>
> On Mon, Oct 31, 2011 at 2:27 AM, John Moser <john.r.moser at gmail.com>wrote:
>
>> 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.
>>
> I think this is the idea used by nexenta by mounting / on a ZFS partition,
> Can a similar approach used for ubuntu ? But that needs / to be mounted on
> a brtfs filesystem, Does that need a thorough reinstall of the system ?
> This approach along with package saved state can help to create a break
> free upgrade mechanism as is done in nexenta currently.
>
>>
>> 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
>> >
>> >
>>
>
>
>
> --
> Thanks and Regards ,
> Gaurav
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20111031/e3643599/attachment.html>