Hello John, <div class="gmail_quote">On Mon, Oct 31, 2011 at 2:27 AM, John Moser <<a href="mailto:john.r.moser@gmail.com">john.r.moser@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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. </blockquote><div>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 ? </div> <div>This approach along with package saved state can help to create a break free upgrade mechanism as is done in nexenta currently.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class="h5"> On Sun, Oct 30, 2011 at 4:40 PM, Bear Giles <<a href="mailto:bgiles@coyotesong.com">bgiles@coyotesong.com</a>> 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 <<a href="mailto:grvsaxena419@gmail.com">grvsaxena419@gmail.com</a>> > wrote: >> >> Hello all >> >> On Fri, Oct 7, 2011 at 4:45 AM, Bear Giles <<a href="mailto:bgiles@coyotesong.com">bgiles@coyotesong.com</a>> 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 <<a href="mailto:grvsaxena419@gmail.com">grvsaxena419@gmail.com</a>> >>> wrote: >>>> >>>> Hello Aaron >>>> Thanks a lot for your quick reply. >>>> >>>> On Fri, Sep 30, 2011 at 10:03 AM, Aaron C. de Bruyn <<a href="mailto:aaron@heyaaron.com">aaron@heyaaron.com</a>> >>>> 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 <<a href="mailto:grvsaxena419@gmail.com">grvsaxena419@gmail.com</a>> >>>>> 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 >>>>> > <a href="https://wiki.ubuntu.com/SystemRestore" target="_blank">https://wiki.ubuntu.com/SystemRestore</a>. >>>>> > -- >>>>> > Thanks and Regards , >>>>> > Gaurav >>>>> > >>>>> > -- >>>>> > Ubuntu-devel-discuss mailing list >>>>> > <a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com">Ubuntu-devel-discuss@lists.ubuntu.com</a> >>>>> > Modify settings or unsubscribe at: >>>>> > <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss</a> >>>>> > >>>>> > >>>> >>>> >>>> >>>> -- >>>> Thanks and Regards , >>>> Gaurav >>>> >>>> >>>> >>>> -- >>>> Thanks and Regards , >>>> Gaurav >>>> >>>> -- >>>> Ubuntu-devel-discuss mailing list >>>> <a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com">Ubuntu-devel-discuss@lists.ubuntu.com</a> >>>> Modify settings or unsubscribe at: >>>> <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss</a> >>>> >>> >> >> >> >> -- >> Thanks and Regards , >> Gaurav > > > -- > Ubuntu-devel-discuss mailing list > <a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com">Ubuntu-devel-discuss@lists.ubuntu.com</a> > Modify settings or unsubscribe at: > <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss</a> > > </div></div></blockquote></div> <div> </div>-- Thanks and Regards , Gaurav