[ale] Backing Up and Restoring Fedora 30 KDE Plasma Spin

[DJ-Pfulio]

Or dump the DB to text while it is running and backup the system with
the expectation that a restore might require using that DB dump to
restore a corrupted DB.  This is extremely common, especially for DBs of
10GB or less in size across corporation around the world.

$ more backup-redmine-db.sh
#!/bin/bash
DB_NAME=redmine_854934562
BACKDIR=/root/backup/
/usr/bin/mysqldump -u root \
    -p`cat ~root/bin/$DB_NAME.passwd.root` $DB_NAME | \
    /bin/gzip > $BACKDIR/${DB_NAME}_`date +%Y%m%d`.gz
/usr/bin/find $BACKDIR -type f -name $DB_NAME\* -atime 60 -exec rm {} \;
#   People who know me will laugh at the 'cat' above. ;)

Or take the DB/App offline for the 1-2 min it requires to write the DB
backup, bring it back online and backup the rest of the running system.

However, I use the LVM snapshot method.

tar is fine for backups of tiny areas, but really, use a real backup
tool that does versioned, incremental, "pull"ed backups. There are so
many that just work it isn't really worth dealing with tar anymore.
rdiff-backup, duplicity, borg, rsnapshot (terrible name!), rbackup, and
there are 50+ others which are all better than tar for 99.99999% of us.
 Tar was designed when 250MB was considered huge. Basically, use tar
like you would a ZIP file, but not for system backups.

Please.

And stop using plain FTP already. Use sftp and if you don't need any
encryption, use rsync without an ssh tunnel or nc over a pipe.

On 10/21/19 9:32 PM, Jim Kinney via Ale wrote:
> 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.
> 
> 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.
> 
> Or use lvm and snapshots. Then external copy to drive.
> 
> Or don't make mistakes 😝
> 
> On October 21, 2019 9:15:24 PM EDT, Jeff Hubbs via Ale <ale at ale.org> wrote:
> 
>     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.
> 
>     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.
> 
>     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.
> 
>     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.
> 
>     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.
> 
>     On 10/21/19 7:49 PM, Ryan Spencer via Ale wrote:
>>     Ideally, I want to be able to restore my computer like how you can
>>     restore VM's with snapshots - to a previous state.??
>>
>>     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).
> 
>