Porteus Application Data Backup Solution?

[FURRY_NOVA]

Is there any proper Porteus application data backup solution? I've been researching since I don't wanna keep making a new dat container and personalizing all the applications over and over again each update. I've found that folders with . prefix in guest directory have the stuff. But I thought I ask here to make sure since I don't pointlessly pass previous Porteus version problems on to the new container.

Module stuff I want to pass:
- Abiword - settings
- Bluefish - code style coloring
- Opera - bookmarks, customization, cookies, plug-ins
- GIMP - saving defaults
- Screensaver - settings

If possible and if error free related to base:
- Desktop - icon order, wallpaper
- Firewall - settings
- Panel - layout, luncher shortcuts
- Power Manager - brightness, settings
- Thunar - shortcut links, view as setting
- Whisker Menu - favorites

I know I'd have to re-enter WiFi due to recent issue though.

I appreciate any help, guys.

[Bogomips]

Probably need

Code: Select all

root@porteus:/home/guest# save-changes

save-changes /path/to/resulting/module.xzm

You must give a path to save your changes to.

Don't normally use it, brokenman swears by it. Reckon this is procedure:

• Start with barebones xfce
• Set up all apps etc.

• Code: Select all

  save-changes initialization_module.xzm

• Store in modules folder
• Bear in mind contents of save.dat could overwrite initialization_module setup
• Use boot parameter (cheatcode) cliexec=activate~/mnt/sdXy/porteus/optional/initialization_module.xzm if you always wish to start off with these settings (module placed in optional folder).

[Ed_P]

Probably need

Code: Select all

root@porteus:/home/guest# save-changes

save-changes /path/to/resulting/module.xzm

You must give a path to save your changes to.

!! I've never heard of it. A 3.2 app? Any documentation as to what changes are backed up? Using Porteus for several hours results in many changes not all are desirable to be saved. I'm thinking some of the cache folders I'm fighting with.

What I have been doing with 3.2 when the changes= option wasn't working is running a find command after i make certain tweaks:

Code: Select all

find /mnt/live/memory/changes  -iname "*" -mmin - 2

Determining the pertinent files changed then manually customizing a script to save the changes as a module.

Code: Select all

#!/bin/bash

# Save 3.2 changes as a mod file 

# Color definitions
txtbld=$(tput bold)               # Bold
txtred=${txtbld}$(tput setaf 1)   # Red
rst=$(tput sgr0)                  # Reset

function redpswd() {
  echo -e "$1" $txtred  
}

if [ `whoami` != "root" ]; then
    redpswd "Enter root's password"
    su -c "sh $0 $1"
    exit
fi
echo $rst

if [ "$1" == "x" ]; then
   echo 'find /mnt/live/memory/changes  -iname "*" -mmin -3'
   find /mnt/live/memory/changes  -iname "*" -mmin -3
   echo
   exit
fi

if [ -d /tmp/mod/ ]; then
   rm -rf /tmp/mod
fi
mkdir -p /tmp/mod

# copy modified files
cp -a --parents    /home/guest/.config/nemo/*                     /tmp/mod/
cp -a --parents    /home/guest/.config/gtk-3.0/*                  /tmp/mod/
cp -a --parents    /home/guest/.config/dconf/*                    /tmp/mod/
cp -a --parents    /home/guest/.cache/dconf/*                     /tmp/mod/
cp -a --parents    /home/guest/*                                  /tmp/mod/

cp -a --parents    /home/guest/.mozilla/firefox/profiles.ini      /tmp/mod/
cp -a --parents    /home/guest/.mozilla/firefox/dxsqumip.default/places.sqlite  /tmp/mod/
cp -a --parents    /home/guest/.mozilla/firefox/dxsqumip.default/prefs.js       /tmp/mod/

cp -a --parents    /home/guest/.cinnamon/configs/[email protected]/* /tmp/mod/
cp -a --parents    /home/guest/.cinnamon/configs/[email protected]/*           /tmp/mod/

cp -a --parents    /etc/NetworkManager/system-connections/*       /tmp/mod/
cp -a --parents    /var/lib/dhcpcd/*                              /tmp/mod/
cp -a --parents    /var/run/NetworkManager/*                      /tmp/mod/

cp -a --parents    /usr/share/applications/cups*                  /tmp/mod/
cp -a --parents    /usr/share/applications/*print*                /tmp/mod/

cp -a --parents    /etc/usm/*                                     /tmp/mod/
cp -a --parents    /var/usm/                                      /tmp/mod/

du -h /tmp/mod/

echo
echo Press Enter to create module, Ctrl+C to end.
read

dir2xzm /tmp/mod /tmp/mychanges.xzm   &&   rm -rf /tmp/mod

echo 
ls -sh  /tmp/*.xzm
read

I copy the resulting module to a folder that I extramods= when I boot an AF mode boot option.

[Bogomips]

^ AFAIK saved changes are cumulative.

@ Ed_P you probably want:

Code: Select all

root@porteus:/home/guest# changes-time

Use this script save Porteus changes made in definied time period.
Enter time interval or press enter for keeping default value (3 minutes):
0
Following folders will be excluded by default: /dev, /home, /mnt, /root, /tmp
mv: cannot stat '/tmp/work2132//mnt/live/memory/changes': No such file or directory
all files created/modified in last 0 minutes were copied to /root/changes2132 folder

[Ed_P]

@ Ed_P you probably want:

Code: Select all

root@porteus:/home/guest# changes-time

Thanks Bogomips. I looked at that quite awhile ago. I didn't like that it would create a module without an option to review the /tmp/ folder to see what was going to be included in the module. If you make a change then run the app it includes everything that was changed in the past 3 minutes but maybe you only needed the last 1 minute. Yes you can rerun it but you've already spent time creating the prior module. Or 2 files changed but you only want to backup one of them. etc

I'll have to look at it again. Maybe I can tweak a version to fit my needs.

[Bogomips]

If you make a change then run the app it includes everything that was changed in the past 3 minutes but maybe you only needed the last 1 minute.

Code: Select all

root@porteus:/home/guest# changes-time

Use this script save Porteus changes made in definied time period.
Enter time interval or press enter for keeping default value (3 minutes):
0

Or if undesirable to be time bound:

• Save change at point A
• Save changes at point B.
• Compare directories.
• Make script to get the difference. Should be quite a challenge for Programming Section:

  Code: Select all

  sudo save-changes ch_a.xzm
  # Do some processing to generate required changes
  sudo save-changes ch_b.xzm
  mkdir a b
  sudo mount ch_a.xzm  a
  sudo mount ch_b.xzm  b
  diff  -qr  b  a
  # Rest of script to get Difference
  ...
  

[Ed_P]

If you make a change then run the app it includes everything that was changed in the past 3 minutes but maybe you only needed the last 1 minute.

Code: Select all

root@porteus:/home/guest# changes-time

Use this script save Porteus changes made in definied time period.
Enter time interval or press enter for keeping default value (3 minutes):
0

Yes I know. But sometimes I make mistakes: forget the time interval or press Enter inadvertently.

Or if undesirable to be time bound:

• Save change at point A
• Save changes at point B.
• Compare directories.
• Make script to get the difference. Should be quite a challenge for Programming Section:

  Code: Select all

  sudo save-changes ch_a.xzm
  # Do some processing to generate required changes
  sudo save-changes ch_b.xzm
  mkdir a b
  sudo mount ch_a.xzm  a
  sudo mount ch_b.xzm  b
  diff  -qr  b  a
  # Rest of script to get Difference
  ...
  

Thank you Bogomips. A very clever idea.

[port]

• Use boot parameter (cheatcode) cliexec=activate~/mnt/sdXy/porteus/optional/initialization_module.xzm if you always wish to start off with these settings (module placed in optional folder).

what's the difference of doing that (save module in optional folder and run activate via cliexec kernel parameter) and simply put the module in modules folder (which is loaded automatically at boot time)?

[port]

Is there any proper Porteus application data backup solution? I've been researching since I don't wanna keep making a new dat container and personalizing all the applications over and over again each update. I've found that folders with . prefix in guest directory have the stuff. But I thought I ask here to make sure since I don't pointlessly pass previous Porteus version problems on to the new container.

all program configuration issues are stored in hidden folders in user home folder, usually inside .config folder so copying content of .config folder would be enough but saddly there're also programs using the old style of having it own config folder under user home, i.e. .mplayer so your best bet is to copy .config folder and every hidden folder you are interested in, so if you make a module from .config folder and maybe adding some other hidden files and save it in a secure place you are covered.

normally, when you install a new program from sources or package manager you have the option not to overwrite user config files and so should be the case when using porteus modules because they shouldn't write anything in user folder

in the case of a new install or a full udpate (i.e. rewriting a usb with new porteus iso) you simply has to copy this previously made .config.xzm module to modules folder and you will end up with your previous configuration (note this will also be the case if you had a changes file in a secure place and you reuse it but trickier)

All the stuff you want to pass about programs (Abiword, bluefish, thunar, opera...) are covered this way, the only issue is you cannot select a subset of config settings to preserve, it's a matter of all or nothing becaose hidden config folder contains all configuration, if you want only a few setting you should manually hack the files under the hidden config folder and this won't be always easy

The other config settings you consider are a different beast, they are system config settings and they're not stored in a per user basis (sometimes there're user config settings taking preference over system ones). System config settins are stored mainly in /etc folder and you need root privileges to manage them. You also need a rather deep knowledge of system to know where to look for and what to tweak. For example, to backup firewall settings you need to know they're stored in a file named rc.FireWall which is located in /etc/rc.d/ Sometimes settings are scattered through several files so each case is a different world. The conservative solution is simply to backup complete /etc but this is not a good idea because new install defines its own settings in /etc you don't want to overwrite.


Do you think it woud be interesting a kind of tracker system just to manage these things in a newbie friendly way ?

[Bogomips]

what's the difference of doing that (save module in optional folder and run activate via cliexec kernel parameter) and simply put the module in modules folder (which is loaded automatically at boot time)?

The difference is it's optional. Sticking to the KISS principle named the optional folder, as that's where people tend to put their optional modules. (If loading from ISO file the modules folder is not easily accessible without remastering the ISO.) It could have been cliexec=activate~/mnt/sdXy/Path/to/module.xzm, if you wished.

Quite simply if one did not wish to start with the saved settings for some reason or other, the command line can be edited at the boot screen and cliexec parameter removed. Just a matter of convenience really. Programmer has in mind all eventualities and best practical way to meet them. Therefore opted for making this optional.

[Ed_P]

What I do, periodically, is copy my porteussave.dat file to another folder, rename it porteussave.dat.xzm and load it as a module either when I boot or when I want via an activate.

[port]

What I do, periodically, is copy my porteussave.dat file to another folder, rename it porteussave.dat.xzm and load it as a module either when I boot or when I want via an activate.

assuming porteussave.dat is your changes file I don't think it were a good practice neither a solution for upgrading porteus. While you keep yourself in same porteus version it's ok but if you upgrade to a newer porteus version loading your old changes file as a module may overwrite files changed in new version and thus causing system malfunction

[Ed_P]

^Yup. A new release means a new save.dat file and a new set of configuration changes. Most of my /home/guest/ files I copy over to new systems and some of my scripts need to be tweaked to the new system's environment. I use firefox as my browser so I backup my bookmarks on one system and restore them to the firefox on the new system.

[brokenman]

For more control over saved folders please look at 'magic folders' in Porteus Settings Centre.

IMPORTANT NOTE:
If invoking save-changes directly from a terminal please be aware that you need to supply a 'real file system' for the target module. You can't create the resulting module anywhere on the live file system (e.g. /tmp /home)

It essentially just packs everything in the changes folder into a module.

[Queensney]

For more control over saved folders please look at 'magic folders' in Porteus Settings Centre.

IMPORTANT NOTE:
If invoking save-changes directly from a terminal please be aware that you need to supply a 'real file system' for the target backup. You can't create the resulting module anywhere on the live file system (e.g. /tmp /home)

It essentially just packs everything in the changes folder into a module.

Thanks for the tip. I forgot supplying a real file system and the backup process failed.