Hi there,

I just published to the public scrutiny a new Slackware tool:

The repository URL is: https://github.com/denydias/drp

The README.md in the URL above contains the first set of documentation on how to use DRP.

Now I ask the fellow Slackware community to take a look at it. The reason for that is simple: make it fail to make it better.

I'm widely open to all patches, pull requests or issues reported to this new tool.

I thanks in advance to every one of you that eventually help make this tool better.

Best,

It looks interesting, but I'm concerned about the long recovery times. For most (if not all) problems I've had a complete re-install is not necessary. Can this tool still recover a previous state without full re-install ? Does it actually save time from doing it manually ?

Hi, metaschima.

I'm glad you have asked! I'll try me best to clearly answer those.

No! Not at all.

DRP is designed based on a single use case: a total disaster. It's going to be helpful only in the case when you loose everything, e.g. when your machine is lost (by you or by the force of an accident) or stolen. In that case, the person who did lost the Slackware box is, by any chance, facing one or more of these situations:

1. Very upset;
2. Stressed by the overall context (herself or a beloved one might be injured);
3. Facing a deadline;
4. Work pressure;
5. Many others stressful situations...

I'm assuming here that some DRP (the plan, not this tool) was done before, even the most basic and poorly designed one. As such there is even a rudimentary 'previous state' to start with. If there is 'no previous state', well... Why bother. :P

To recover from a 'previous state' without any automation help, one might have to remember a lot of commands and procedures that, if not continuously trained and repeated, are very easy to forget. To remember these complex procedures becomes even harder in a stressful situation. This is where DRP (this tool) becomes useful.

As a side effect, a good DRP (the plan) make it easy to rebuild a system from nothing to any of the well know and tracked states. This could be useful to install from the ground other boxes that one might need. DRP (this tool) helps with that too.

Of course, DRP (this tool) can be easily modified by the user to start from any of its phases. As such, you can have a spare installation somewhere that you just want to start from there. I just don't see the point on keeping an up-to-date Slackware spare installation if DRP just can take care of this to you.

Keep in mind that DRP (this tool) helps one implement a reasonable and safe DRP (the plan) from the ground up.

Yes! But only if doing from the blue.

I was a Mac OS X user for many years. In the OS X days (although I still own a functional MacBook Pro with OS X), once Time Machine feature was introduced, it was very handy a couple of times. One I had my Macbook Air stolen, the other I have had a bad HD. When the hardware was ready to get my software back, Time Machine could handle it in about 3~8 hours. This 'how long' factor greatly depends on external variables such as file transfer bandwidth (a firewire direct connected disk is faster than a networked one).

After the initial Time Machine recover is done and you boot the machine to the last registered state, Mac OS X start doing its things (mostly indexing Spotlight search). This renders the system barely usable for some other 2~6 hours (depending if you are in a rotational disk or SSD and the amount of data you have).

So, the best case scenario for a full Mac OS X recovery is about 5h. This was my benchmark when developing DRP.

The complete DRP process using this tool, IN MY CASE, WITH MY EXTERNAL VARIABLES, is about 4h30m. It is long, indeed. But I can assure you this is a fraction of the time required by doing it by hand from the ground. By testing the same DRP by hand (a thing that I repeated over and over before get all the steps needed to develop the tool), I took about twice the time.

I can assure you: I don't want to even think about all those manual steps when I see myself on a situation that my Slackware box is gone. Those 4h30m are going to be pure bless!

Btw, I'm about to commit some improvements to DRP. Check it out later.

Thank you for you questions and feel free ask more.

Best,

1 members found this post helpful.

As promised, the improvements are published:

https://github.com/denydias/drp/commits/master

They are the ones starting at Sep 10, 2014.

I would appreciate if the MOD publish my reply to @metaschima.

Tks in advance.

I understand, and I agree that the tool would be faster in a stressful situation.

I'm looking for a tool that is a bit more flexible. I mean if one package was corrupted, it would be easier to scan the system, detect the error and just re-install the package instead of the whole system. Well, either way, the tool does have its use, just not quite what I need.

Thanks, @metaschima! That's precisely the use case it was designed to help with.

I wish you find the right tool for your requirements.

Best,

Throw rocks at me but one thing I wish Linux had was the Windows's System Restore or Mac OS's Time Machine. If it has something like that, I am unaware. Because if I got what OP said right it is not like Windows's System Restore (which is a very nice feature).

@moisespedro: Use a continuously snapshotting filesystem. I used to have my /home partition mounted as NILFS2 to allow me to mount old snapshots of /home in a previous state.

EDIT: You could find out a little bit more about how NILFS2 works in this older IBM article.

2 members found this post helpful.

You got it absolutely right! DRP is not like Windows System Restore. DRP is about to recover a most recent state of a Slackware box into a brand new machine. Chances are that you've got this new machine because the old one has been lost forever.

But there's a catch: if you have implemented DRP right in the preparation steps, you already have snapshots for the last month of at least your box configuration in /etc and the full /home. So, if the user or a misbehaved package does something nasty on those places, that user could just count on these snapshots to recover the faulty piece.

If you're looking for a Windows System Recover clone, well... Windows System Recover 'per se' is a clone of a quite old *nix feature: rsync/rsnapshot. Just have your entire filesystem under rsync/rsnapshot and you are able to restore any particular faulty piece to any working state covered by your retention time span. OS X's Time Machine itself goes further: it is an implementation of rsync snapshots under the hood.

I choose to not cover the whole filesystem with DRP because for what it is designed for (to recover from a disaster), I can just reapply the old box package layout to a fresh Slackware install using well know package management tools (although not standard) like Slackpkg+ and sbopkg. To get the whole filesystem covered would be just a waste of resources, specifically the time to create the snapshots, network usage and space required to store them.

Best,

1 members found this post helpful.

Thank you both for the answers, I will take a look at the suggestions.

Check out btrfs..

Small tutorial for snapshots: http://www.linux.com/learn/tutorials...n-linux-part-2