LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   How do you avoid system crashes/misbehavior? (http://www.linuxquestions.org/questions/slackware-14/how-do-you-avoid-system-crashes-misbehavior-4175489710/)

moisespedro 12-31-2013 11:04 AM

How do you avoid system crashes/misbehavior?
 
I mean, like, preventing crashes/misbehavior before updates. Something like backup tools/scripts. I would say something like Windows's system restore. I am asking this because I am trying to use Slackware as my main desktop for the first time ever and, since I don't know much, I am afraid of breaking my system or having it acting weird (like this) after so many hours spent configuring it the way I want.

mlslk31 12-31-2013 01:00 PM

For the "saved configuration" part of Windows System Restore, know that your system configuration files are saved mostly in /etc, sometimes in /usr/etc and /usr/local/etc as well depending on how you update. Per-user settings are stored in the home directories, usually in folders that start with a dot, such as .kde or .openoffice.org. These are shown by the `ls -a` command.

To backup, you can use tar, maybe use getfacl to back up ACLs separately (if you use ACLs). If you're using XFS as your filesystem, xfsdump works much better than tar.

If you have to absolutely wind everything back to a certain point, though, you might consider using a filesystem that supports snapshots, such as btrfs or NILFS2. Keep in mind that btrfs is a moving target and NILFS2 lacks fsck: A healthy backup regimen is helpful when using both filesystems. Both filesystems have learning curves associated with them, but at the end of the day, any filesystem you use will have a learning curve.

I use a 50/50 approach to updates. If everything is on fire after 4 of 12 updates, and each one is getting harder and requires more and more reading, I'm going to resort to backup. If everything is on fire after 9 of 12 updates, I'll probably update my way through it, apply updates 13-16 that always seem to be required, and do another backup once everything is *perfect*. Keep in mind that I update a bit using source code.

moisespedro 12-31-2013 02:32 PM

Btrfs got me interested, can it be considered stable? Is it hard to use?

mlslk31 12-31-2013 03:07 PM

Reports vary. On one hand, the btrfs developers classify the filesystem layout as stable, but the code always improves, and it's best to keep up using the latest kernel. On the other hand, at least SuSE was considering it for a default file system. In playing with it, I'm almost certain that you'd be better off using it in a redundant RAID configuration, so that btrfs can compare both sides of the mirror for data/checksum errors. [At last check, the fsck tool was not 100% foolproof.] IOW, it helps to have two or more hard drives in your PC, and let btrfs use a partition off of each one for a filesystem.

btrfs not much harder overall than some other filesystems, but it requires more reading up front--mostly for the "btrfs" command--and the handling of subvolumes means making more mistakes up front as well.

The Web site is here...

https://btrfs.wiki.kernel.org/index.php/Main_Page

...and you can start deciding whether it's just what you're seeking or simply too much work.

Note that, theoretically, you can do snapshots with LVM for any filesystem, and the RAID stuff I've described can be done using mdadm or LVM; so this stuff isn't exclusive to btrfs. However, LVM snapshots seem like a crude hack compared to btrfs snapshots...or at least my attempt was an exercise in frustration whose conclusion was "I did that much work and reading for that?!?"

mlslk31 12-31-2013 03:30 PM

I forgot to add this...

No matter which way you go, just consider "Backups! Backups! Backups!" to be your mantra. A full install of Slackware should back up to a 16 MB USB stick, and those are anywhere from $7 to $14 in my local stores. If you have extra hard drives, you can reserve space for those "in-between" backups on much faster storage.

On Windows, System Restore can be used in any number of ways. I've even seen it used because it's faster than a virus scanner for undoing virus damage: The only problem is that it doesn't necessarily do so, maybe get rid of it, maybe hide it, maybe include a virus in the restore point. There are times when System Restore rollbacks can imperfect and introduce glitches, and it's not always fun to deal with Windows Registry issues. I hope that even on Windows, you practice "Backups! Backups! Backups!" for those situations that System Restore doesn't quite fix.

moisespedro 12-31-2013 04:01 PM

Well, what I was looking foward was a simple way to revert changes (if they mess up something).

nd7rmn8 12-31-2013 04:50 PM

This is probably overkill, but I used to have multiple boot options like this.

1. ubuntu with clonezilla installed for creating and unpacking backups
2. linux distro of the day...
3. same linux distro for testing and breaking...
4. another linux distro?
4. various linux livecd's... (forgot how I did this, but was able to with grub2, twas useful)

I would keep all data worth saving (music, documents) in a seperate partition. If it was worth backing up, it went on a flash drive.

Before I did much work with my linux distro of the day, I would back up that partition, and image it to the testing partition. I would try out what I wanted to do there, if it worked, great, if not, reboot, re-image and try again. I want to say it took only about 10-15 minutes to backup and image as such. This was a while ago, back when grub2 first came out, my memory isn't all that great.

Nowadays, I just take notes on how to do the install quickly and what programs i need to install afterwards. That text file goes on a flash drive, and when I really break stuff, I get more practice reinstalling.

In my personal opinion, the best way to learn how to work on something and fix it, is to break it, and then repair it. Backup all important docs and such, keep a few livecd's handy in case of emergencies, and go play.

mlslk31 12-31-2013 06:15 PM

Goes back to my first reply. If by "they," you mean someone else, reference a backup of home directories. If by they, you mean "you," you can reference either a backup of /etc or a full backup. If you're just upgrading binary packages, you have to re-upgrade back to the older packages. Sometimes, you can get away with, say, upgrading prerequisite libraries in order to upgrade a program, then the program is a dud and has to be backleveled. Sometimes you have to re-upgrade back.

You can look for fancy backup tools, and perhaps somebody knows of one here. However, if it comes down to a data partition and I can make a disaster mistake at any time and need to go back, I deploy a NILFS2 partition and keep regular backups of it (for lack of fsck). It keeps checkpoints on a per-synchronous-write basis, which you can change to snapshots at any time with the chcp command. Old checkpoints are deleted over time. Any snapshot can be mounted read-only so I can get that last bit of correct data off of it. The main tools to learn are lscp, chcp, and rmcp, and they're fairly similar. NILFS2 got the EXPERIMENTAL tag removed from it recently in the kernel config, but your mileage may vary nonetheless.

speck 12-31-2013 10:57 PM

Always keep an up to date backup of at least /etc and /home, but preferably everything if you have the space. After that, only download/build/install software in the package format that Slackware understands (like from Slackbuilds.org). If you do this then the chances are close to zero that a software installation/removal will trigger a need to reinstall Slackware. I can only remember one official package update that was built improperly, but it just installed some files into /tmp instead of the correct directory (I was a couple versions behind the current Slackware and Pat still released a fix within 24 hours).

When you make changes to configuration a file, just make a backup copy before editing the file.


All times are GMT -5. The time now is 02:12 PM.