You are not logged in.
Pages: 1
I am trying to implement the following workflow:
Automate backup of OS partition on boot drive to a different drive on a regular basis (weekly?)
Backups run on a regular basis for some unknown period of time
Boot drive fails
Purchase new drive with storage space >= size of backed up OS partition
Restore latest image to new drive
Plug drive into computer (if not already) and power computer on.
Computer automatically boots to same state it was at at the time of the last backup.
Reasoning: I probably spent weeks trying to install and configure Arch the first time, and I don't remember all the configuration changes I made any more. I don't have weeks to redo it all, and feel that backing up and restoring the whole thing will be quicker.
I've searched for ways to do this, but everything I find says there is absolutely no way to safely back up a running OS, which I know is not true because this is done by VMWare VMotion and IBM Live Partition Mobility. I don't even have a strict requirement to have the OS running at the time, as long as I can automate the process, because I know I won't take the time to manually do this once a week, and even if I was willing to, the work involved in backing up will probably end up being more than recovering afterwards with just a simple rsync script copying individual files and then re-configuring everything from scratch.
Any suggestions?
Offline
I've searched for ways to do this, but everything I find says there is absolutely no way to safely back up a running OS
Where the hell are you searching?
https://lmddgtfy.net/?q=backup%20!aw
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Make it a cron job. You'd need to delete each backup after you make the newest so you don't run out of space.
It may be a better idea to write scripts you can run to configure the arch installation from it's initial state.
For example, this script installs a postfix server and configures a user:
https://github.com/jclifton44/shell-scr … Postfix.sh
It only works on Ubuntu. It could be modified to work with Arch or any other distribution.
Last edited by Jclifton44 (2019-01-07 04:14:20)
"... a high signal to noise ratio..."
Offline
You really shouldn't be publicising your scripting until you have cleaned it up: `cat file | grep ...` Really? Grep, like practically every other utility, takes a file name as an argument.
Offline
You'd need to delete each backup after you make the newest so you don't run out of space.
Proper use of incremental backups with rsync (as described in the wiki) would mitigate this for the most part. You can delete really old backups as needed, but with incrementals you can keep a very large number of snapshots.
EDIT a specific example of JWRs advice:
# YOUR VERSION
cat /etc/s-nail.rc | grep "^set emptystart"
if [ $? -ne '0' ];
then
echo "set emptystart" >> /etc/s-nail.rc
fi
# BETTER VERSION
grep -q '^set emptystart' /etc/s-nail.rc || echo 'set emptystart' >> /etc/s-nail.rc
# ANOTHER OPTION
sed -i '/set emptystat/d;$aset emptystat' /etc/s-nail.rcBut that whole thing is for a debian-based distro, so clearly not an example of what to use here. EDIT 2: I see you have *several* such blocks all working on the same file! A single sed command can specify all three options in the config file.
Last edited by Trilby (2019-01-07 04:33:53)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Jclifton44 wrote:You'd need to delete each backup after you make the newest so you don't run out of space.
Proper use of incremental backups with rsync (as described in the wiki) would mitigate this for the most part. You can delete really old backups as needed, but with incrementals you can keep a very large number of snapshots.
Hi,
BORG could make perfectly the job
Last edited by waitnsea (2019-01-07 05:41:54)
Offline
The (I think) classic discussion on using rsync for snapshotting: http://www.mikerubel.org/computers/rsync_snapshots/
Of course, a number of filesystems these days support native snapshotting facilities, but using software RAID would be an even better move.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Pages: 1