LVM lets you create a snapshot where the mounted filesystem looks normal but under the cover it's using a journal and the original logical volume, e.g., /dev/mapper/vg0/home, is untouched. You can then perform your backup and when you release the snapshot the journal is written to the original volume.
Obviously this requires a backup app that runs against the raw device instead of the mounted filesystem. 'dump' does that, 'tar' does not. On Sun, Oct 30, 2011 at 2:57 PM, John Moser <john.r.mo...@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. > > On Sun, Oct 30, 2011 at 4:40 PM, Bear Giles <bgi...@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 <grvsaxena...@gmail.com> > > wrote: > >> > >> Hello all > >> > >> On Fri, Oct 7, 2011 at 4:45 AM, Bear Giles <bgi...@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 < > grvsaxena...@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 < > aa...@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 <grvsaxena...@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@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@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@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > > > >
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
