Here is the classic problem with backups that clothe live data. This is a well studied problem. Please, just do want the pros do, follow current best practiced you will be fine. Do not re-invent 1970's vintage solutions.
Here are the classic failures: 1) You have a "backup drive" the mirrors all your data. SO after spending a few hours edits files yu save the file but the software has a bug and writes a corrupted file to disk. the yo "backup" the file and this over writes the only good copy of the file, the one you backed up yesterday. So not the file and the backup are corrupted. Solution: NEVER over write a backup. only save the CHANGES. You need to be able to go back in time and pull out the last working version 2) You have a backup disk and it make automated saves every hour and keeps a version history because you read the above. But lightening strikes a power pole 1/4 mile from your house and the surge valve destroys the computer AND the backup disk. Solution: Keep a redundant copy of the data off-line. This done not need to be quite as up to date but it should not be "live". Store it in some other room and no connected to power data cables 3) You have done all of the above but you house burned down. I know you rethinking "my house will not burn down" but EVERYONE who has ever had a fire thought the same thing. An "fire" is a stand-in for many other disasters like food Earthquake or the most common one: Theft of the equipment. Solution: Keep the backup data off-site. The farther off site the better. In another state if you can or at least at your office at work. A basic url of thumb for data that is NOT business critical is that "At all times, even during a a backup, that data shall exist on at least three different physical media and in at least two different geographical locations". For business critical data, that means data that yu need to ear a living that can't be replaced, increment those numbers by one. Four copies of the data in three different locations. Oe of the worst problem is #1. A files that you don't read very often gets corrupted. and then is propagated all over you backup media. This takes some thought to prevent. The ONLY way is versioned backup -- NEVER overwrite old data with new. We can afford to do this because the cost of media falls. In my case I have a primary backup that runs every hour. It is not very big because I can't generate much data in only one hour. This backup goes to the biggest and newest disk I own. Every two years or so I Buy a newer big disk and retire the old one. I wan the the backup to be on the newest and most reliable drive. SO I run the new disk in parallel with the old one and after some time unplug the old one and put it to see other use. Today in 2019 they sell good 8TB drives. That is 4 or 2 times larger then most people need. Botton like is that you can NEVER overwrite backup. The House fire/theft/flood/...problem is easy to solve. Just sign up for a service like "Backblaze" or something like it. For $5 per month they keep a up to date copy of all by files. Software in my computer scenes for changes and imeadeatly sends them to the service. If the house burned down I've have lost not more then maybe 90 minutes of work. $5 is cheaper than buying a disk drive. But the disadvantage is recovering the data. Downloading multiple TB would take forever. But they would for a price send it to me via FedEx on a USB drive Once you set this you can forget about it. It is automated. Because almost everyone actually do some kind of backup now days. The biggest loss of data is no longer hard drive failures like it once was. Today the cause is "loss of the equipment" by theft or accident. On Mon, Jan 14, 2019 at 5:55 AM Dave Cole <[email protected]> wrote: > > > Get a copy of Clonezilla and put it on a stick drive and make it bootable. > https://clonezilla.org/ > It does an effective job of backing up and restoring entire Linux disks > without pain via a graphical interface. > It can also do baremetal restores as well. > > I use a little USB plug in Hard drive along with a USB stick with > Clonezilla to backup my Linux server. It has saved me a few times now > after a few bad installs, and when my server was hacked - twice in one > year. Highly recommended. The small USB hard drive and stick are > stored in a steel cabinet and are never left plugged in - in case of a > lightning strike. > > After I make any sizeable changes, I do a backup and give the backup > file an approprate name and timestamp. That makes fallbacks a lot > easier. > > Dave > > > On 1/13/2019 7:46 PM, Gene Heskett wrote: > > Greetings all; > > > > In search of something, anything that might give me a clue as to why > > about a months work on custompanel.xml was killing linuxcnc, I installed > > xmlindent, and xmlcopyeditor. > > > > Thinking I might find a clue in the re-indented code, I checked the man > > page for xmlindent. But it has only a -option for an output file. So I > > ran it. Never came back, so I added the -w option. Never came back. > > > > Opps, now I have a zero length file where it was 130+ LOC with an error > > of some sort that let it load up to the final </pyvcp> before it puked > > at column 2. I can get most of it back by dragging it in from another > > machine with a similar setup but to restore what I had 20 minutes ago > > will take a hell of a lot longer than I have left in me for tonight. So > > then I tried xmlcopyeditor, thinking I could copy/paste into that. But > > its apparently only for new creation as it does not accept a paste. > > WTF?? > > > > So where can I find an xml editor that will let me copy/paste from the > > Document.pdf, most of the stuff from pages 392 on to get an rpm meter, > > on, fwd, rev leds, and append align.xml stuffs to that with added status > > leds to show the current machine alignment state, and which will also > > show any errors (cuz the Doc.pdf has quite a few errors of its own). > > > > And preferably not capable of destroying several weeks worth of work over > > the last 5 years? > > > > I know this isn't your fault, none of you wrote this stuff, but this xml > > bs needs warning labels because it can destroy anybodies sanity. > > > > Thanks everybody. > > > > Cheers, Gene Heskett > > > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users -- Chris Albertson Redondo Beach, California _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
