| View previous topic :: View next topic |
| Author |
Message |
moult
Retired Dev
Joined: 31 Mar 2008
Posts: 146
Location: Australia
|
 Posted: Thu Jan 12, 2017 8:55 pm Post subject: How to snapshot a Gentoo system? |
 |
|
Let's say I have a Gentoo box that has been running for a while. Apart from a whole disk snapshot, how do you recommend I store the state of this machine such that if the hardware broke, I could recreate the machine?
I'm thinking:
1) /var/lib/portage/world and world_sets
2) Install a fresh Gentoo, install world from above, and diff /etc with it to see exactly what configuration changes I've made.
3) Regular dumb file backup of /home (assuming that I've kept things neat and all user content is within there)
4) Regular dump file backup of /opt for custom packages
Anything else?
_________________
thinkMoult - I write articles online. You might like some of them.
Planet Larry - do you write a blog and use Gentoo? Get your blog added to the Planet Larry Gentoo user blog aggregator! |
|
| Back to top |
|
 |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3151
|
| Posted: Thu Jan 12, 2017 11:16 pm Post subject: |
|
|
Depending on what piece of hardware failed, you may be able to just move the hard drive to a new box.
RAID is pretty good at guarding against disk failures.
Stage4 tarball or rsync hardlinked backup. Recovering from those will most likely require manual actions (preparing disks, reinstalling bootloader), but if you only have a few machines, it doesn't really matter.
Preparing tarball or running rsync you can skip /tmp, /proc, /sys /usr/portage, /usr/src and maybe some more directories storing either recoverable or temporary data. Well, the system itself is recoverable if you have your settings and metadata, but I'd rather copy it back in it's place than rebuild it from scratch (or world file). Hard-linking new backups to previous backup makes it pretty space efficient and makes every single backup look like full backup. Handy thing. |
|
| Back to top |
|
|
moult
Retired Dev
Joined: 31 Mar 2008
Posts: 146
Location: Australia
|
| Posted: Fri Jan 13, 2017 3:11 am Post subject: |
|
|
These are all remote accessed machines (e.g vps or dedis bought online), so moving the hard drive isn't an option.
I don't know what a stage 4 tarball is, but are you basically suggesting backing up the entire drive excluding some system folders like proc? Because you think it's easier than building from scratch? This assumes I am not changing architectures from machine to another.
_________________
thinkMoult - I write articles online. You might like some of them.
Planet Larry - do you write a blog and use Gentoo? Get your blog added to the Planet Larry Gentoo user blog aggregator! |
|
| Back to top |
|
|
Jaglover
Watchman
Joined: 29 May 2005
Posts: 8291
Location: Saint Amant, Acadiana
|
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Fri Jan 13, 2017 8:09 am Post subject: |
|
|
snapshoot functionality of lvm2
--
Personally I use this.
3 SSD drives => A-> B -> C -> A ... repeat
The drive which will be used again in my notebook will be put in an external case. The notebook SSD is than copied to the external SSD. The external SSD is replaced with the build in one. The internal one goes on my shelf as backup.
Procedure:
Boot up 1 year sysrescue-cd, as I need that grub bootloader version.
Recreate / reuse the partition layout according to the gentoo handbook on the external drive
mount existing gentoo installation and boot in the live environment.
mount the backup mount points.
cp -avr /boot_root /boot_backup
cp -avr /root /backup_root
Takes less than 20 minutes from SSD 128GB -> 120GB. ~60GB in use for /. Basically after a shower I am done. Just replacing the SSDS, and reinstalling the UEFI GRUB links, becasue of UEFI limitations.
the distfiles are on my 2nd 1TB drive, those do not need to be backuped.
some tmpfs folders in my fstab
Full backups which works. It'S instantly tested because the build in drive goes on the shelf. The exteranl drive is swapped in.
Backup in my eyes means a full system backup. I just need to replace the drive, and reinstall the uefi bootloader.
There is also some time backup of the history, because I have 3 drives. 2 Drives with older states of /
It is highly unlikely that 3 different manufactuerer SSDS fails. I still have my first SSD in this cycle, which is now around 5 years old. With two brand new drives, each around 6 months old
--
You can do of course rsnapshoots, lvm2 snapshoots, tar ...
--
Regarding first post.
You have to take your time also in account.
round up values: 20 min here for the copy procedure + 10 min for installing the bootloader(yes optical drives are very slow) + 10 min for swapping the drive.
Of course you can backup only a subset of folders.
Reinstalling gentoo takes quite a while, is it really worth that? with these days discs?
time is the most valueable ressource! |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21724
|
| Posted: Sat Jan 14, 2017 1:51 am Post subject: |
|
|
| I tend to agree with Jaglover about minimum required content. For a full restore, you need backups of any files you cannot effectively recreate through package installation. That means any user personal files (/root, /home), enough to know which packages you installed (/var/lib/portage/world, etc.), and the ability to reapply any customizations (any changed files in /etc and other $CONFIG_PROTECT directories). If possible, grab also the CONTENTS files of all your installed packages so that you can identify which files from /etc are actually customized by you. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Jan 14, 2017 10:11 am Post subject: |
|
|
| Hu wrote: | | [...] If possible, grab also the CONTENTS files of all your installed packages so that you can identify which files from /etc are actually customized by you. |
Hu ... something like the following:
| Code: | | # find /var/db/pkg/ -name "CONTENTS" -exec awk '/^obj\s\/etc/{print $3,$2}' {} + | md5sum -c 2>/dev/null | awk '/FAILED/{gsub(/:/,"") ; print $1}' |
... or (as we previously discussed zsh's 'glob qualifiers' and 'zargs') using zsh:
| Code: | | # zargs /var/db/pkg/**/CONTENTS*(.) -- awk '/^obj\s\/etc/{print $3,$2}' | md5sum -c 2>|/dev/null | awk '/FAILED/{gsub(/:/,"") ; print $1}' |
best ... khay |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Sat Jan 14, 2017 12:51 pm Post subject: |
|
|
| khayyam wrote: |
| Code: | | # find /var/db/pkg/ -name "CONTENTS" -exec awk '/^obj\s\/etc/{print $3,$2}' {} + | md5sum -c 2>/dev/null | awk '/FAILED/{gsub(/:/,"") ; print $1}' |
|
I would be tempted to take a copy of /etc tree ... changes from defaults in a package may not catch all information - for example manually created config information or things in /etc not claimed to be owned by any package (which I think you helped with when I was trying to setup tripwire).
For installs on recent systems I have created /etc_manually_modified and /etc_manually_modified_machine_specific trees, move things I want to change from /etc to one of the two trees and symlink to it from /etc. While this has the advantage of everything I modify handy it does have a few issues as well:-
1. I had problems and ended up with hardlinks for a few things like passwd,shadow,sudoers,group,gshadow
2. portage updates to etc and dispatch-conf dont put things in quite the place I expected so for manually modified things I end up having to do updates manually
3. on a fresh install after copying /etc_manually_modified and /etc_manually_modified_machine_specific I have to put the symlinks / hardlinks back in /etc
I'm sure something like git might be able to help me out with some of these issues, failing that I could automate things a bit with a script. I could also probably do with having a look at dispatch-conf setup to see if I can get it to work with my setup. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Sat Jan 14, 2017 3:28 pm Post subject: |
|
|
| jonathan183 wrote: | | For installs on recent systems I have created /etc_manually_modified and /etc_manually_modified_machine_specific trees |
That's similarly how I do it. I have three directories which I backup: "all" "only" "various".
"various" contains the data which is identical on all machines and which can be symlinked (e.g. from /etc).
"all" contains these symlinks as well as all other data which is identical which cannot be symlinked.
"only" contains machine specific data.
All three directories have subdirectories starting with etc/... (which is the main bulk) but some others also starting with usr/... var/... boot/...
| Quote: | | 2. portage updates to etc and dispatch-conf dont put things in quite the place I expected so for manually modified things I end up having to do updates manually |
I am only using etc-update and have written a wrapper to it (which defines an "mv()" function so that it it follows symlinks appropriate to my setup and then sources the original etc-update). I suppose for dispatch-conf one can do something similar (or patch it). |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Jan 14, 2017 3:43 pm Post subject: |
|
|
| jonathan183 wrote: | | khayyam wrote: | | Code: | | # find /var/db/pkg/ -name "CONTENTS" -exec awk '/^obj\s\/etc/{print $3,$2}' {} + | md5sum -c 2>/dev/null | awk '/FAILED/{gsub(/:/,"") ; print $1}' |
|
I would be tempted to take a copy of /etc tree ... changes from defaults in a package may not catch all information - for example manually created config information or things in /etc not claimed to be owned by any package (which I think you helped with when I was trying to setup tripwire). |
jonathan183 ... certainly, particularly if you're using '<service>.<runlevel>', however, the above was specifically in reference to what Hu suggested (ie, if you simply wanted to find those package installed files that had been modified).
| jonathan183 wrote: | | For installs on recent systems I have created /etc_manually_modified and /etc_manually_modified_machine_specific trees, move things I want to change from /etc to one of the two trees and symlink to it from /etc. While this has the advantage of everything I modify handy it does have a few issues as well:- |
This sounds as though you want to be using puppet ... dispatch-conf's 'archive-dir' might also do the trick as you could use this rather than create a separate tree, this way you have a backup of all files under CONFIG_PROTECT stored under /etc/config-archive/path/to/file (which in your case could be under git and have /etc/config-archine/etc/$file-$MACHTYPE for those where you need to distribute such a file).
| jonathan183 wrote: | | 1. I had problems and ended up with hardlinks for a few things like passwd,shadow,sudoers,group,gshadow |
I'm not sure about your use case but I would consider that if you need to share these then you probably should be looking at LDAP for authentication.
| jonathan183 wrote: | | 2. portage updates to etc and dispatch-conf dont put things in quite the place I expected so for manually modified things I end up having to do updates manually |
Hmmm ... doesn't that defeat the purpose somewhat?
| jonathan183 wrote: | | 3. on a fresh install after copying /etc_manually_modified and /etc_manually_modified_machine_specific I have to put the symlinks / hardlinks back in /etc |
Again, I think puppet is probably what you want for such deployments, doing anything like this by hand should be avoided if possible ... it sounds like more work, and is potentially more error prone, than having separate configs for each machine.
best ... khay |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21724
|
| Posted: Sat Jan 14, 2017 5:47 pm Post subject: |
|
|
| khayyam wrote: | | Hu wrote: | | [...] If possible, grab also the CONTENTS files of all your installed packages so that you can identify which files from /etc are actually customized by you. |
Hu ... something like the following:
| Code: | | # find /var/db/pkg/ -name "CONTENTS" -exec awk '/^obj\s\/etc/{print $3,$2}' {} + | md5sum -c 2>/dev/null | awk '/FAILED/{gsub(/:/,"") ; print $1}' |
|
That is a neat approach, although as johnathan183 mentioned, it would be safer to capture unowned files too. Create a list of all files in /etc. Remove from that list any file which is owned and which is unmodified (according to CONTENTS). The resulting list gives you files that are unowned and files that are owned-but-modified. Given the relatively small size of /etc, I would be tempted to archive the whole of /etc, and all the CONTENTS files, then apply the exclusions at reinstall time. That way, if I cannot readily get the same package version at reinstall time (and therefore cannot trust that the file installed in /etc is what the old system would have started from), I can get exactly what the old system had and handle merging by hand. This might be desirable if upstream changes its defaults in a way that I dislike (or even a way that breaks some assumptions I made elsewhere). Keeping upstream's new default may be the right choice, but knowing that it changed and how will inform the decision of whether to revert or adapt. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Sat Jan 14, 2017 8:06 pm Post subject: |
|
|
| khayyam wrote: | | jonathan183 wrote: | | 1. I had problems and ended up with hardlinks for a few things like passwd,shadow,sudoers,group,gshadow |
I'm not sure about your use case but I would consider that if you need to share these then you probably should be looking at LDAP for authentication. |
I think that there is a misunderstanding: "Sharing" probably means here "sharing on the backup" so that one can easily restore the "common" settings which one wants in a freshly set-up (virgin) gentoo system.
jonathan183 is probably not speaking about a computer farm but about very few individual machines, perhaps on distinct locations not connected over any net.
| Quote: | | jonathan183 wrote: | | 2. portage updates to etc and dispatch-conf dont put things in quite the place I expected so for manually modified things I end up having to do updates manually |
Hmmm ... doesn't that defeat the purpose somewhat? |
I agree: Without hacking up the tools as I described, these tools become almost useless.
| Quote: | | Again, I think puppet is probably what you want for such deployments, doing anything like this by hand should be avoided if possible ... |
I think the main purpose is not to do the same thing scripted on dozens of machines but to have a tiny backup of perhaps 1MB so that you can restore all your systems easily "from scratch" using only this backup data even in the worst case if all go havoc.
But even if you want to use it for automation, the described mechanism is simple: You do the changes in the backup once and then copy the common content to all machines (by a simple script). Only the "individual" changes (not common to all machines) have to be scripted (or manually repeated) somehow. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Jan 14, 2017 10:54 pm Post subject: |
|
|
| Hu wrote: | | khayyam wrote: | | Code: | | # find /var/db/pkg/ -name "CONTENTS" -exec awk '/^obj\s\/etc/{print $3,$2}' {} + | md5sum -c 2>/dev/null | awk '/FAILED/{gsub(/:/,"") ; print $1}' |
|
That is a neat approach, although as johnathan183 mentioned, it would be safer to capture unowned files too. Create a list of all files in /etc. Remove from that list any file which is owned and which is unmodified (according to CONTENTS). The resulting list gives you files that are unowned and files that are owned-but-modified. |
Hu ... tentatively I offer this quicky to do just that:
| Code: | #!/bin/bash
etc_lst="$(mktemp --suffix=".lst" "${TMPDIR:-/tmp}/etc_XXXXX")"
unmodified_lst="$(mktemp --suffix=".lst" "${TMPDIR:-/tmp}/unmodified_XXXXX")"
file_lst="$(mktemp --suffix=".lst" "${TMPDIR:-/tmp}/file_XXXXX")"
find /etc -type f -print | sort -d >> $etc_lst
find /var/db/pkg/ -name "CONTENTS" -exec awk '/^obj\s\/etc/{print $3,$2}' {} + | \
md5sum -c 2>/dev/null | \
awk '/OK/{gsub(/:/,"") ; print $1}' | \
sort -d >> $unmodified_lst
if [[ -s $etc_lst && -s $unmodified_lst ]] ; then
grep -Fvf $unmodified_lst $etc_lst >> $file_lst
tar -cjf ~/etcfiles-$(hostname)-$(date +%F).tar.bz2 -T $file_lst 2>/dev/null
else
echo "* Unable to continue as one of the file lists is empty."
fi
rm -f $etc_lst $unmodified_lst $file_lst |
| Hu wrote: | | Given the relatively small size of /etc, I would be tempted to archive the whole of /etc, and all the CONTENTS files, then apply the exclusions at reinstall time. |
I guess I was thinking that the reason for selecting specific files was so that it could be unpacked into / and so reproduce the previous setup, but now that I think about it I'm probably less inclined.
| mv wrote: | | I think the main purpose is not to do the same thing scripted on dozens of machines but to have a tiny backup of perhaps 1MB so that you can restore all your systems easily "from scratch" using only this backup data even in the worst case if all go havoc. [...] |
In which case I would restore from backups, the space required isn't that much if you're only talking about a few machines. That is why I thought jonathan183 was talking more in terms of deployment, because the effort didn't seem worth the bother if it's only a couple of machines.
best ... khay
edit: made some changes/additions/corrections to the above script.
Last edited by khayyam on Sat Jan 21, 2017 2:51 am; edited 1 time in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Sun Jan 15, 2017 12:04 am Post subject: |
|
|
| khayyam wrote: | | In which case I would restore from backups, the space required isn't that much |
I am obviously not talking about enterprise systems who hardly can afford any downtime and for which having several fallback machines and several TB of backup space ready is a negligible cost.
For a "normal" user, a difference between about 1-2M and perhaps 60-100G times the number of machines is enormous, I would say.
Apart from the space requirement: If a machine gets replaced or upgraded, and the new one is not downward compatible (I had this e.g. when changing 32bit->64bit, intel->amd or vice versa), it is much quicker to get a running system if you know what you need just to copy and what to adapt; the remainder of a backup is practically useless. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Jan 15, 2017 2:33 am Post subject: |
|
|
| mv wrote: | | khayyam wrote: | | In which case I would restore from backups, the space required isn't that much |
I am obviously not talking about enterprise systems who hardly can afford any downtime and for which having several fallback machines and several TB of backup space ready is a negligible cost. For a "normal" user, a difference between about 1-2M and perhaps 60-100G times the number of machines is enormous, I would say. |
mv ... that simply isn't the case:
| df -h: | Filesystem Size Used Avail Use% Mounted on
mdev-tmpfs 10M 56K 10M 1% /dev
/dev/mapper/vg-root 9.8G 4.1G 5.2G 45% /
tmpfs 201M 168K 201M 1% /run
/dev/mapper/vg-var 5.8G 1009M 4.5G 19% /var
/dev/mapper/vg-home 276G 229G 47G 83% /home
shm-tmpfs 1003M 0 1003M 0% /dev/shm |
So, vg-root and vg-var are a little over 5G, of which 1.7G is distfiles, 566M is ~portdir, and 2.8G is /usr/src ... that is a trivial amount to backup. vg-home is where most of the data is, but that you need to backup regardless. Additionally, you needn't backup everything, your rsync_excludes could simply target those files you're targeting in your 1.2M, with the advantage that it can be under revision (and so you can rollback to a specific backup, etc, etc). Disk space is cheap, cheaper than time, effort, and cpu cycles ... I'd rather boot a USB stick, mount the backup disk, and rsync a known working backup, than have to rebuild the entire system simply because I thought I might save a couple of gigabytes.
| mv wrote: | | Apart from the space requirement: If a machine gets replaced or upgraded, and the new one is not downward compatible (I had this e.g. when changing 32bit->64bit, intel->amd or vice versa), it is much quicker to get a running system if you know what you need just to copy and what to adapt; the remainder of a backup is practically useless. |
You're changing the use case, in the above we are talking about "restor[ing]", and "worst case[s]", that is what I was responding to when I stated "in which case I would restore from backups".
best ... khay |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Sun Jan 15, 2017 1:25 pm Post subject: |
|
|
| mv wrote: | That's similarly how I do it. I have three directories which I backup: "all" "only" "various".
"various" contains the data which is identical on all machines and which can be symlinked (e.g. from /etc).
"all" contains these symlinks as well as all other data which is identical which cannot be symlinked.
"only" contains machine specific data.
All three directories have subdirectories starting with etc/... (which is the main bulk) but some others also starting with usr/... var/... boot/...
Quote:
2. portage updates to etc and dispatch-conf dont put things in quite the place I expected so for manually modified things I end up having to do updates manually
I am only using etc-update and have written a wrapper to it (which defines an "mv()" function so that it it follows symlinks appropriate to my setup and then sources the original etc-update). I suppose for dispatch-conf one can do something similar (or patch it). |
Thanks mv splitting out hardlinks and symlinks is probably something I should do.
| khayyam wrote: | | Code: | #!/bin/bash
etc_lst="$(mktemp --suffix=".lst" "${TMPDIR:-/tmp}/etc_XXXXX")"
unmodified_lst="$(mktemp --suffix=".lst" "${TMPDIR:-/tmp}/unmodified_XXXXX")"
file_lst="$(mktemp --suffix=".lst" "${TMPDIR:-/tmp}/file__XXXXX")"
find /etc -type f -print | sort -d >> $etc_lst
find /var/db/pkg/ -name "CONTENTS" -exec awk '/^obj\s\/etc/{print $3,$2}' {} + | md5sum -c 2>/dev/null | awk '/OK/{gsub(/:/,"") ; print $1}' | sort -d >> $unmodified_lst
if [[ -f $etc_lst && -f $unmodified_lst ]] ; then
grep -Fvf $unmodified_lst $etc_lst >> $file_lst
rm -f $etc_lst $unmodified_lst
tar -cjf ~/etcfiles-$(hostname)-$(date +%F).tar.bz2 -T $file_lst
rm -f $file_lst
fi |
|
Thanks khayyam - I can see that being very useful for me  |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Jan 15, 2017 1:58 pm Post subject: |
|
|
| jonathan183 wrote: | | Thanks khayyam - I can see that being very useful for me 8) |
jonathan183 ... you're welcome, note that its not well tested, I can already see one small problem, the test should really check if the file is non-zero rather than if it exists (we know the file exists as we've made it with mktemp).
| Code: | | if [[ -s $etc_lst && -s $unmodified_lst ]] ; then |
best ... khay |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Sun Jan 15, 2017 3:53 pm Post subject: |
|
|
| khayyam wrote: | | mv ... that simply isn't the case |
We could spend hours to discuss how large a "typical" gentoo installation is. Without counting data from other partitions like /home or /srv, all my installations are at least 25-30 GB, usually larger. distfiles and gentoo repository are counted here only in a cleaned up and compressed form, and many directories like /usr/src /usr/lib/libreoffice /usr/share/texmf-dist are kept compressed (using squashmount); if I would uncompress them, I would probably have another 5-15 GB more data. And many things are not installed (e.g. no KDE or Gnome stuff, no large games, ...).
| Quote: | | You're changing the use case |
I don't think the use case was specified very clearly; that's why I specified for which case my suggestion is good for. Of course, everybody must decide by himself which use-case matches best to him. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Sun Jan 15, 2017 3:59 pm Post subject: |
|
|
In addition to khayyam's script: qcheck shows you a list of modified files.
To get a list of unowned files, I recommend find_cruft from the mv overlay: This has a rather short running time (main time is needed to hunt through the directories) and can be extensively configured to exclude false positives and deal with symlinks correctly. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Jan 15, 2017 5:06 pm Post subject: |
|
|
| mv wrote: | | khayyam wrote: | | mv ... that simply isn't the case |
We could spend hours to discuss how large a "typical" gentoo installation is. |
mv ... we don't need to, I provided the only one necessary to make my "case", and comment, valid.
The reason I keep it simple is so that when it comes to things like backups, maintainance, etc, its not a problem ... that looks like its circling back to our discussion of simplicity in design and I'd rather not return to that quagmire.
| mv wrote: | | Without counting data from other partitions like /home or /srv, all my installations are at least 25-30 GB, usually larger. distfiles and gentoo repository are counted here only in a cleaned up and compressed form, and many directories like /usr/src /usr/lib/libreoffice /usr/share/texmf-dist are kept compressed (using squashmount); if I would uncompress them, I would probably have another 5-15 GB more data. And many things are not installed (e.g. no KDE or Gnome stuff, no large games, ...). |
You brought it on yourself ;)
| mv wrote: | | khayyam wrote: | | You're changing the use case |
I don't think the use case was specified very clearly; that's why I specified for which case my suggestion is good for. Of course, everybody must decide by himself which use-case matches best to him. |
It was pretty clear what the case was, if I needed to "restore all [my] systems easily", "I would restore from backups", you then jumped to "enterprise systems" and how much data is involved (which as we see is the result of you how happen to do things) and then to "changing 32bit->64bit" (which wasn't part of the "in the worst case if all go havoc" my comment was in reference to).
best ... khay |
|
| Back to top |
|
|
lebarondemerde
n00b
Joined: 01 Nov 2016
Posts: 26
|
| Posted: Tue Jan 17, 2017 3:40 pm Post subject: |
|
|
I would use ZFS remote snapshots. So, creating strategic volumes for what I want to have backup/snapshots, and then sending those snapshots to somewhere, like FreeNAS (to make it simple).
I am not versed on BTRFS but I think it does not support remote snapshots yet. Please correct me if I am wrong on it.
EDIT: since we are talking about a already working machine, it would need a lot of work to manually migrate everything to a new FS but still worth (IMO).
Cheers! |
|
| Back to top |
|
|
moult
Retired Dev
Joined: 31 Mar 2008
Posts: 146
Location: Australia
|
| Posted: Thu Jan 19, 2017 8:52 pm Post subject: |
|
|
Wow, this blew out of control somewhat.
There seems to be a little confusion between whether I was asking for a way to deploy a state of a system or whether I was more interested in backing up the entire system, or whether I wanted to "snapshot" a system ie. Record the system's state to be replicated in a fresh install.
I am not interested in large scale deployment - puppet, ansible, do great jobs at that. As for full-time backups, ZFS snapshots and full hard drive backups are commonplace. What I am interested in is recording the state of an _existing_ gentoo system.
All the answers seem to be on the same track with only minor differences: a Gentoo system consists of user files (/home, and others) , a list of packages (world, world_sets) , and package configurations (/etc) . Ignoring slight complications such as 3rd party packages (/opt, or non FHS standard installs), it should be relatively easy to convert a fresh install to a "snapshotted" existing install by 1) copying over user files, 2) installing packages from world, and 3) using some diff for /etc.
_________________
thinkMoult - I write articles online. You might like some of them.
Planet Larry - do you write a blog and use Gentoo? Get your blog added to the Planet Larry Gentoo user blog aggregator! |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Fri Jan 20, 2017 12:11 am Post subject: |
|
|
| Moult wrote: | | All the answers seem to be on the same track with only minor differences: a Gentoo system consists of user files (/home, and others) , a list of packages (world, world_sets) , and package configurations (/etc) . Ignoring slight complications such as 3rd party packages (/opt, or non FHS standard installs), it should be relatively easy to convert a fresh install to a "snapshotted" existing install by 1) copying over user files, 2) installing packages from world, and 3) using some diff for /etc. |
My suggested order would be:-
1. use your diff tool of choice to restore changed /etc
2. if needed emerge changed use @system
3. emerge your kernel of choice
4. restore your /usr/src/linux/.config (or grab a kernel seed if different hardware etc), check/modify the config to suit the hardware, build and install the kernel
5. emerge world packages for which you only really need the list of packages
You can copy over user files before or after the above.
If you have overlays it is likely to be worth copying that information over also ... as others have said a backup can save some or all of the build process and whether it is worth having it depends on your particular use case. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
