<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">I like just tarball of /etc and /root and /home (this is a laptop) that goes periodically to an external drive. Total screw up is new install, untar, done.<br><br>There's a flag in tar (um, duh, there's 35,000,000) that is perfect for backups as it sets the backed up flag. Next tar only pull unset files. A monthly total copy resets flags. Very old school.<br><br>Or use lvm and snapshots. Then external copy to drive.<br><br>Or don't make mistakes 😝<br><br><div class="gmail_quote">On October 21, 2019 9:15:24 PM EDT, Jeff Hubbs via Ale <ale@ale.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="moz-cite-prefix">You *can* try to back up a running
system via tar or rsync, but it's really not a safe way to go; if
it's a database server and the daemon is running while its files
are read, you can forget about having a reliably restorable
instance.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">If you can stand the downtime, the
absolute safest thing to do is to bring the system down, boot it
to e.g. SystemRescueCD, mount the partitions readonly in the same
tree arrangement that you ordinarily boot with, and *then* tar or
rsync the mount point contents off somewhere. A hybrid alternative
method is to utilize some sort of kernel snapshotting (lvm or
appropriate filesystem function) behavior, close everything you
can close down momentarily, fix your snapshot, put everything back
in running condition again, and then tar/rsync from the
readonly-mounted snapshot.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">In the case of database servers it's
really best to just stay clear of the DBMS daemon's disk space
entirely and use its dump/restore powers, whether you write the
dump output to the machine's own disk and then back up the system
a la the above or write the dump out to somewhere/something else.
<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Even VM snapshots need care with
respect to what's running while the snapshot is being taken. The
basic problem is the same no matter how the volume data is copied.
<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I've heard of people running backups of
system(s) and then performing a restore back to the same system(s)
*every night*. Can't say their restore process ever want untested.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 10/21/19 7:49 PM, Ryan Spencer via
Ale wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+X6GPJoLa0J6eMyasDOj4wKrvvXiL6O=1dxVJMd7cp9LdNeGA@mail.gmail.com">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Ideally,
I want to be able to restore my computer like how you can
restore VM's with snapshots - to a previous state.??<br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">So
far, I have checked out tools like rsync and Borg but I am
uncertain of how to exactly use them in my use case. I just
don't want to blow up my system (again... Can neither confirm
nor deny that I have had to reflash Fedora back on to my
computer 3 times in the span of a week).</div>
</blockquote>
<p><br>
</p>
</blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.</body></html>