BACKUP SERVER
• Startpagina
• Server Hardware
• Raspberry OS Lite
• Configureren
• Backup en Restore
• Samba
• Utility Scripts

 

Backup-Server::Backup en Restore

Backup op de Raspberry Pi

De 3-2-1 backup strategie adviseert één copie van je data op een andere locatie te bewaren. Veel organisaties beschouwen opslag in de cloud als afdoende - en veel cloud-providers moedigen dit aan.
Maar in feite blijven de data 'online'in de cloud en zijn dus kwetsbaar voor ransomware. Alleen Air-gapping de backup storage zorgt ervoor dat de data niet van afstand aangevallen kunnen worden.

Om automatisch en frequente off-line backups te maken we gebruik van deze Backup-Server op een Raspberry Pi 4

NOTE:
Zelfs air-gapping backups heeft zijn kwetsbaarheden. Elke keer als een backup gemaakt wordt, naar bijvoorbeeld een externe disk, is deze disk (tijdelijk) 'online'. Als het daarbij gaat om grote data volumes en redelijk hoge frequentie dan houdt dit in dat de backupstorage nog steeds niet zo air-gapped is als we zouden wensen.

Om zo dicht mogelijk bij de aanbevolen strategie te komen richten we op een Raspberry Pi4 een Linux Backup-Server in met de volgende condities:

1. De Backup-Server is per default uitgeschakeld.
   Door middel van een stopcontact met een Hue tijdschakelaar wordt de server dagelijks om 12:00 uur gestart en om 15:00 opnieuw gestopt.
    
2. De backupdata worden opgeslagen op een externe USB-disk. Bij het opstarten van de Backup-Server wordt deze disk niet gemount en blijft zodoende off-line.
    
3. De Backup-Server bevindt zich buiten de woning en heeft een Powerline verbinding met het thuisnetwerk.
    
4. De Backup-Server is vanaf het thuisnetwerk niet bereikbaar, is Read-only, heeft geen gedeelde bestanden en is wachtwoord beveiligd.
    
5. Door middel van een cron start de Backup-Server de Thuisserver-backups dagelijks om 12:05 uur
   De PC Image-backup wordt manueel gestart met UTILS > IMAGES-BACKUP en de Testserver met UTILS> TESTSERVER-BACKUP
    
6. Thuisserver-backup
   Als eerste wordt gecontroleerd of de bron in orde is.
   De bron van de Thuisserver-Backup is de 'vault' op de 3e HDD van de thuisserver. In deze vault is tevens een controle bestand geplaatst. Het is een tekstbestand met daarin een specifiek woord.
   Als dit bestand niet gevonden wordt en/of niet geopend kan worden en/of het specifieke woord niet bestaat (encrypted?), wordt ervan uitgegaan dat de Thuisserver geheel of gedeeltelijk geransomed is.
   In dat geval verbreekt de Backup-Server de verbinding, stuurt een e-mail naar Admin en schakelt zich vervolgens uit (#shutdown now).
    
   Als het controlebestand wel in orde is wordt de externe USB SSD gekoppeld en middels RSYNC gesynchroniseerd met //thuisserver/vault.
   Zodrade synchronisaties uitgevoerd zijn wordt de externe USB-SSD ontkoppeld en vervolgens schakelt de Backup-Server zich zelf uit.
    
7. Images-backup
   Hetzelfde proces als in 6 wordt uitgevoerd voor het synchroniseren van de Macrium Reflect PC-Images die opgeslagen zijn op de Admin PC.
   Dit zijn over het algemeen erg grote bestanden die weinig veranderen. Deze backups worden naar behoeven op de hand uitgevoerd.
   Zodra de synchronisaties uitgevoerd zijn wordt de externe USB-SSD ontkoppeld en vervolgens schakelt de Backup-Server zich zelf uit.
    
8. Pi-Sysback
   We maken handmatig regelmatig, na bijv. wijzigingen/toevoegingen in het OS, een image van de Raspberry Pi OS Lite op de SD-kaart en slaan deze op op de Admin PC.
   Van deze wordt zoals in punt 7 genoemd een backup naar de Backup-Server geschreven.
   Toch maken we aanvullend een routinematige backup in een tarball van het Systeem van de Backup-Server.

Naar index

Gescheiden Backup-processen

De backups die naar de Backup-Server gesynchroniseerd worden zijn groot en kan enkele uren duren. Vooral de Macrium Reflect PC-Images zijn groot en synchronisatie kan wel tot 5 uur oplopen.

Backup processen één voor één

De Thuisserver-backup start middels een CRON (zie hierboven punt 5). De Images-backup start handmatig naar behoeven.
Als één van bovenstaande backups gestart is mag er absoluut geen tweede starten. Dit zou tot een crash leiden met als resultaat dat beide processen mislukken

Controlebestand als vlag

In elk backup-proces wordt er een controlebestand gedownload naar /home/ben/tmp/. Pas als het proces succesvol afgerond is wordt het controle bestand verwijderd.
Dus zolang een backup in voortgang is staat er een controlebestand in /home/ben/tmp en dit kan als vlag gebruikt worden

Direct aan het begin van de Thuisserver-Backup code middels de Proces-vlag gecheckt of er een ander proces (Images-Backup) actief is.
Het script 'images-backup' draait naar behoeven en duurt al snel een paar uur. Het script 'thuisserver-backup start dagelijks om 12:05 uur.
Zolang 'images-backup' draait is het controlebestand /home/ben/tmp/pcs-ransom.txt
Om een conflict te voorkomen wordt script 'thuisserver-backup' afgebroken als er een bestand /home/ben/tmp/pcs-ransom.txt bestaat.
De server wordt niet gestopt , het script 'images-backup' is immers nog bezig!

Crash-check :: Cron bij boot

Door bijv. een stroomstoring of een clash in de synchronisatie wordt een backup-proces vroegtijdig beeindigd en wordt ook het controlebestand niet verwijderd.
Als de Backup-Server opnieuw geboot wordt zal vervolgens het nog aanwezige controlebestand elke nieuwe backup blokkeren.

Met het script 'crash-check' wordt gecontroleerd of één van de controlebestanden nog aanwezig is. Zo ja dan wordt er een waarschuwings-mail naar Admin verstuurd en vervolgens wordt het controlebestand verwijderd.
Het script 'crash-check' wordt elke (re)boot uitgevoerd dmv een CRON:
@reboot /usr/local/bin/crash-check

Script 'crash-check'
Bekijk hier het complete script.

# **********************************************************************************************
# * BACKUP-SERVER 'on boot' script  Ben Makkink   15-sep-2024  Raspberry Pi 4 Backup server    *
# * Als de Backup-Server onverhoeds stopt omdat bijvoorbeeld de power uitvalt of uitgeschakeld *
# * wordt dan staat het controlebestand nog in /home/ben/tmp en is er ook de incomplete backup *
# * Dit 'on boot' script start met de CRON @reboot /usr/local/bin/crash-check en checkt of er  *
# * nog een controle bestand aanwezig is en zo ja dan wordt Admin gewaarschuwd                 *
# * en vervolgens het controlebestand verwijderd.                                              *
# **********************************************************************************************
#!/bin/bash

# Check of controlebestand thuisserver-ransom.txt bestaat, zo ja dan is de laatste Thuisserver-Backup vroegtijdig gecrasht
if [ -f /home/ben/tmp/thuisserver-ransom.txt ]; then
  echo;
  echo "De laatste Thuisserver-Backup is mislukt";
  echo;
# Delete controlebestand
  rm -rf /home/ben/tmp/thuisserver-ransom.txt;
# Wacht tot boot compleet en msmtp beschikbaar
  sleep 15;
# Stuur e-mail naar Admin
  echo "Stuur notificatie";
  cat /home/ben/thuisserver-backup-crash.txt | msmtp ben@makkink.eu;
  echo;
fi

# Check of controlebestand testserver-ransom.txt bestaat, zo ja dan is de laatste Testserver-Backup vroegtijdig gecrasht
if [ -f /home/ben/tmp/testserver-ransom.txt ]; then
  echo;
  echo "De laatste Testserver-Backup is mislukt";
  echo;
# Delete controlebestand
  rm -rf /home/ben/tmp/testserver-ransom.txt;
# Wacht tot boot compleet en msmtp beschikbaar
  sleep 15;
# Stuur e-mail naar Admin
  echo "Stuur notificatie";
  cat /home/ben/testserver-backup-crash.txt | msmtp ben@makkink.eu;
  echo;
fi

# Check of controlebestand pcs-ransom.txt bestaat , zo ja dan is de laatste Images-Backup vroegtijdig gecrasht
if [ -f /home/ben/tmp/pcs-ransom.txt ]; then
  echo;
  echo "De laatste Images-Backup is mislukt";
  echo;
# Delete controlebestand
  rm -rf /home/ben/tmp/pcs-ransom.txt;
# Wacht tot boot compleet en msmtp beschikbaar
  sleep 15;
# Stuur e-mail naar Admin
  echo;
  echo "Stuur notificatie";
  cat /home/ben/pcs-backup-crash.txt | msmtp ben@makkink.eu;
  echo;
fi

Stap voor stap
Als eerste wordt gecontroleerd of het thuisserver-backup controlebestand bestaat. Bij een thuisserver-backup crash blijft dit bestand achter.
Dit bestand wordt verwijderd om te voorkomen dat nieuwe backup processen geblokkeerd worden.

# Wacht tot boot compleet en msmtp beschikbaar
  sleep 15;
# Stuur e-mail naar Admin
  echo "Stuur notificatie";
  cat /home/ben/thuisserver-backup-crash.txt | msmtp ben@makkink.eu;
  echo;
fi

Als het controlebestand bestond wordt er een notificatie naar Admin gestuurd dat de laatste testserver-backup vroegtijdig is gecrasht.

Ten tweede wordt gecontroleerd of het testserver-backup controlebestand bestaat. Dezelfde procedure wordt gevolgd als bij de Thuisserver-backup

# Check of controlebestand pcs-ransom.txt bestaat , zo ja dan is de laatste Images-Backup vroegtijdig gecrasht
      if [ -f /home/ben/tmp/pcs-ransom.txt ]; then
      echo;
      echo "De laatste Images-Backup is mislukt";
      echo;
      # Delete controlebestand
      rm -rf /home/ben/tmp/pcs-ransom.txt;

Vervolgens wordt gecontroleerd of het images-backup controlebestand bestaat. Bij een images-backup crash blijft dit bestand achter.
Dit bestand wordt verwijderd om te voorkomen dat nieuwe backup processen geblokkeerd worden.

      # Wacht tot boot compleet en msmtp beschikbaar
      sleep 15;
      # Stuur e-mail naar Admin
      echo;
      echo "Stuur notificatie";
      cat /home/ben/pcs-backup-crash.txt | msmtp ben@makkink.eu;
      echo;
      fi     

Als het controlebestand bestond wordt er een notificatie naar Admin gestuurd dat de laatste mainserver-backup vroegtijdig is gecrasht.

Naar index

Thuisserver-Backup

Met de Backup-Server maken we met het script 'thuisserver-backup' een complete backup van //thuisserver/vault, die alle backups bevat van de PC's in het netwerk, van de Fileserver en van de Webserver.

Met een crontab wordt het script 'thuisserver-backup' dagelijks uitgevoerd en kan aanvullend naar wens op de hand uitgevoerd worden via het 'UTILS' Utilitiespakket.

Naar index

Cron voor thuisserver-backup
5 12 * * * /usr/local/bin/thuisserver-backup >> /var/log/backup/thuisserver-backup.log
Dagelijks om 12:05 uur start script 'thuisserver-backup'.
Verbose logdata worden toegevoegd aan bestand thuisserver-backup.log Zie hieronder Logrotate

Naar index

Logrotate
In bovenstaande cron wordt aangegeven dat logdata toegevoegd worden aan het bestand /var/log/backup/thuisserver-backup.log
Als er verder geen maatregelen genomen worden zal dit een enorm groot bestand worden.
Hiertoe nemen we dit bestand op in de logrotate procedure. Zie # man logrotate.

Configureer voor Thuisserver-backup.log

Check of /etc/logrotate.conf en /etc/logrotate.d bestaan.
Zo ja voeg een bestand met een toepasselijke naam zoals ‘backup’  in /etc/logrotate.d met de volgende inhoud:

/var/log/backup/thuisserver-backup.log {
compress
weekly
missingok
rotate 4
}

Het logbestand homeserver-backup.log wordt wekelijks geroteerd en gecomprimeerd. De bestanden worden 4 keer geroteerd voordat ze verwijderd worden.

/var/log/backup/images-backup.log {
compress
monthly
missingok
rotate 6
}

Het logbestand images-backup.log wordt maandelijks geroteerd en gecomprimeerd. De bestanden worden 6 keer geroteerd voordat ze verwijderd worden.

Om logrotate te testen:
ben@pi-nas:~ $ sudo logrotate --force /etc/logrotate.d/backup

Naar index

Script thuisserver-backup stap voor stap
Bekijk hier het complete script.

Het proces stap voor stap:

# **********************************************************************************************
# * THUISSERVER-BACKUP script  Ben Makkink   09-feb-2025       Raspberry Pi 4 Backup server    *
# * De backup drive is per default niet gemount en dus airgapped t.o.v. het thuisnetwerk       *
# * Eerst controleren we een bestand in de vault van de thuisserver. Als deze bestaat en tevens*
# * niet encrypted is, kunnen aannemen dat de thuisserver vrij van ransomware is en kunnen we  *
# * de externe backup drive mounten en synchroniseren met de /vault van de thuisserver         *
# **********************************************************************************************
#!/bin/bash
echo;
echo "  Thuisserver-Backup start: "$(date +%d/%m/%Y-%X);
echo "  =============================================";

# Start timer
begin=$(date +"%s");

# bug systemd still uses old version fstab
systemctl daemon-reload;
# wait;

Als eerste wordt de starttijd weergegeven voor in de log.
 
Vervolgens wordt de starttijd opgeslagen in de variabele 'begin'. Deze wordt aan het einde gebruikt voor het berekenen van de tijd die nodig was voor de synchronisatie.
Als we een mount van de SSD proberen te doen komt er telkens de waarschuwing 'systemd still uses old version fstab'. Het advies is de daemon opnieuw te laden: # systemctl daemon-reload;
 
We voegen regelmatig het commando 'wait'; in om te voorkomen dat het script verder gaat terwijl het laatste commando nog bezig is.

Proces-vlag

# Check of Images-Backup draait, zo ja dan kan Thuisserver-Backup niet starten!
if [ -f /home/ben/tmp/pcs-ransom.txt ]; then
  echo;
  echo "CONFLICT!";
  echo "Images-Backup is bezig, nu geen Thuisserver-Backup";
  sleep 10;
  exit;
fi

Naar index

Met bovenstaande code wordt gecheckt of er een ander proces actief is.
Het script 'images-backup' draait slechts handmatig naar behoefte maar duurt al snel een paar uur. Het script 'thuisserver-backup start dagelijks om 12:05 uur.
In beide scripts wordt aan het begin een zgn controle bestand geladen in /home/ben/tmp.

Zolang 'images-backup' draait is dit het bestand /home/ben/tmp/pcs-ransom.txt
Om een conflict te voorkomen wordt script 'thuisserver-backup' afgebroken als er een bestand /home/ben/tmp/pcs-ransom.txt bestaat.
De server wordt niet gestopt , het script 'images-backup' is immers nog bezig!

# Per default is de externe backup drive niet gekoppeld, maar we controleren het toch nog even
# een keer voordat we de airgap sluiten 
if mountpoint -q "/store"; then
   umount -l /store;
   wait;
   echo "  De backup drive was nog gemount en is nu ontkoppeld";
fi

De externe backup drive is normaal niet gekoppeld om de airgap in stand te houden.
En na elke mount voor synchronisatie wordt de SSD opnieuw ontkoppeld. Maar bijv. door een crash van het programma kan het gebeuren dat de SSD nog gekoppeld is.
We willen voordat er verbinding met de thuisserver gemaakt wordt, zeker stellen dat de SSD niet gekoppeld is.

Als mountpount '/store' bestaat verwijderen we deze.

Controlebestand

# Verwijder mogelijk nog achtergebleven controlebestand /home/ben/tmp/thuisserver-ransom.txt
  rm -rf /home/ben/tmp/thuisserver-ransom.txt;

# check of op de thuisserver het controle bestand bestaat en niet encrypted is.
 sshpass -f ~/.rsync_pass_thuisserver rsync -azh --exclude '*/' ububen@192.168.178.4:/vault/* /home/ben/tmp/;

if [ -f /home/ben/tmp/thuisserver-ransom.txt ]; then
    if grep -q "\bransomware-check\b" /home/ben/tmp/thuisserver-ransom.txt; then

Om vast te stellen dat de thuisserver geen ransomware bevat is in //thuisserver/vault een z.g.n. controletekstbestand 'thuisserver-ransom.txt' geplaatst.

Voordat we dit bestand downloaden maken we zeker dat er geen oud controlebestand achtergebleven is:
rm -rf /home/ben/tmp/thuisserver-ransom.txt;

Vervolgens wordt, indien het bestand bestaat op de thuisserver, gedownload naar /home/ben/tmp
sshpass -f ~/.rsync_pass_thuisserver rsync -azh --exclude '*/' ububen@192.168.178.4:/vault/* /home/ben/tmp/;
Zie voor rsync met sshpass: Backup Server::Configureren SSH

Indien het bestand bestond en gedownload kon worden wordt gecontroleerd of het bestand leesbaar is door te zoeken naar een exact woord.
if grep -q "\bransomware-check\b" /home/ben/tmp/thuisserver-ransom.txt
Als dit niet het geval is dan gaan we er van uit dat de thuisserver met ransomware besmet is en we beindigen het process

Naar index

if [ -f /home/ben/tmp/thuisserver-ransom.txt ]; then
    if grep -q "\bransomware-check\b" /home/ben/tmp/thuisserver-ransom.txt; then

       # Het controle-bestand in //thuisserver/vault is in orde.
       # Het is veilig de externe Backupdrive te koppelen voor synchronisatie.
       echo "  Het controlebestand op de thuisserver is in orde, mounting SSD....";
       mount UUID=138d237d-dae1-4c0f-8246-b766b1d33737 /store;
       wait;
       echo "  Start Rsync van Thuisserver naar BackupServer";
       echo "  --------------------------------------------";
        sshpass -f ~/.rsync_pass_thuisserver rsync -avzh --delete ububen@192.168.178.4:/vault/* /store/vault/;
       wait;
       echo "  Einde Rsync van Thuisserver naar BackupServer";
       echo "  --------------------------------------------";
       # Na de synchronisatie ontkoppelen we de externe drive
       umount -l /store;
       wait;
       echo;
       echo "  Einde Rsync en SSD ontkoppeld :"$(date +%d/%m/%Y-%X);
       echo "  ==================================================";
       # Stop timer
       einde=$(date +"%s");
       DIFF=$(($einde-$begin));
       echo "  Duur backup: $(($DIFF / 3600 )) uur $((($DIFF % 3600) / 60)) minuten $(($DIFF % 60)) seconden.";
       echo;
       sleep 5;
       # Verwijder controlebestand /home/ben/tmp/thuisserver-ransom.txt
       rm -rf /home/ben/tmp/thuisserver-ransom.txt;
       wait;
       # shutdown backup-server
       echo "   Backup-Server Shutdown";
       sleep 5;
       shutdown now;
       sleep 5;
       exit;
    fi
fi

Naar index

Als het controle bestand in orde is:

1. Wordt de SSD gekoppeld: mount UUID=138d237d-dae1-4c0f-8246-b766b1d33737 /store;
   Zie ook Backup Server::Configureren Mount externe USB-SSD
    
2. Synchroniseer Thuisserver naar Backup-Server
   sshpass -f ~/.rsync_pass_thuisserver rsync -avzh --delete ububen@192.168.178.4:/vault/* /store/vault;
   
   NOTE: Om leestoegang te krijgen tot de bestanden in 192.168.178.4:/vault/* moet op de Thuisserver de gebruiker 'ububen' toegevoegd worden aan de groep 'backuppc'.
              Zie Server::Backup & Restore > Voeg Admin 'ububen' toe aan groep 'backuppc'
    
3. Ontkoppel de SSD
   umount -l /store;
    
4. Nu wordt de eindtijd weergegeven voor in de log.
   $(date +%d/%m/%Y-%X)
    
5. De eindtijd wordt opgeslagen in de variabele 'einde' om vervolgens de duur van de backup te bereken en weer te geven..
   einde=$(date +"%s");
   DIFF=$(($einde-$begin));
   echo " Duur backup: $(($DIFF / 3600 )) uur $((($DIFF % 3600) / 60)) minuten $(($DIFF % 60)) seconden."
    
6. Het controlebestand wordt nu verwijderd en is daarme tevens indicatie dat het proces afgerond is.
   rm -rf /home/ben/tmp/thuisserver-ransom.txt;
    
7. De Thuisserver-backup is nu afgerond en de Backup-Server wordt nu afgesloten.
   halt;
   exit;
   Het commando 'shutdown now' heeft enige tijd nodig en om te voorkomen dat het script nog verder uitgevoerd wordt voordat de shutdown compleet is onderbreken we het script met 'exit'

Naar index

Exit Ransom

# Het controlebestand //thuisserver/vault/thuisserver-ransom.txt bestaat niet of is versleuteld. Potentieel ransomware!
 echo;
 echo "De thuisserver backupbestanden zijn waarschijnlijk geransomed. Een error mail is verstuurd.";
cat /home/ben/thuisserver-ransom-mail.txt | msmtp ben@makkink.eu;
echo;
echo "Shutdown BackupServer";
sleep 5;
halt;   

Als het controlebestand niet bestaat en/of niet leesbaar is waarschuwen we de Admin met een e-mail
cat /home/ben/thuisserver-ransom-mail.txt | msmtp ben@makkink.eu;

Zie voor msmpt Backup Server::Configureren MSMTP e-mail van commandline
Zie voor inhoud e-mail: /home/ben/thuisserver-ransom-mail.txt

Als laatst wordt de Backup-Server afgesloten
halt;

Naar index

Images-backup

Van de Admin-Windows-PC wordt met Macrium Reflect elke maand een full image gemaakt en vervolgens dagelijks een incremental backup. Deze worden opgeslagen in de Images map van de Admin-Windows-PC. Van alle andere PC's in het thuisnetwerk worden handmatig Full Images gemaakt elke keer dat er aanleiding toe is zoals installatie van nieuwe software. Deze images worden opgeslagen op een externe USB-disk en in de Images map van de Admin-Windows-PC.
Met de Backup-Server maken we met het script 'images-backup' een complete backup van de Windows-PC's Images en de Raspberry Pi Image die opgeslagen zijn op de Admin PC.

Met een crontab kan het script 'images-backup' bijvoorbeeld 1 x per maand uitgevoerd worden, maar omdat de images van ben-pc nogal groot zijn wordt er afgezien van een automatische backup.
Deze wordt op de hand uitgevoerd worden via het 'UTILS' Utilitiespakket nadat eerst het door Hue uitschakelen van de Raspberry tijdelijk is disabled.

Naar index

Script images-backup stap voor stap
Bekijk hier het complete script.

Het proces stap voor stap:

# **********************************************************************************************
# * IMAGES-BACKUP script  Ben Makkink   25-jan-2025      Raspberry Pi 4 Backup server          *
# * De backup drive is per default niet gemount en dus airgapped t.o.v. het thuisnetwerk       *
# * Eerst controleren we een bestand in de Images map van BEN-PC. Als deze bestaat en tevens   *
# * niet encrypted is, kunnen we aannemen dat BEN-PC vrij van ransomware is en kan de externe  *
# * backup drive gemount worden en gesynchroniseerd met de IMAGES map van BEN-PC.              *
# **********************************************************************************************
#!/bin/bash
echo;
echo "  Images-Backup start: "$(date +%d/%m/%Y-%X);
echo "  ========================================";

# Start timer
begin=$(date +"%s");

# bug systemd still uses old version fstab
systemctl daemon-reload;
# wait;

Als eerste wordt de starttijd weergegeven voor in de log.
 
Vervolgens wordt de starttijd opgeslagen in de variabele 'begin'. Deze wordt aan het einde gebruikt voor het berekenen van de tijd die nodig was voor de synchronisatie.
Als we een mount van de SSD proberen te doen komt er telkens de waarschuwing 'systemd still uses old version fstab'. Het advies is de daemon opnieuw te laden: # systemctl daemon-reload;
 
We voegen regelmatig het commando 'wait'; in om te voorkomen dat het script verder gaat terwijl het laatste commando nog bezig is.

Proces-vlag

# Check of Thuisserver-Backup draait, zo ja dan mag Images-Backup niet starten!
if [ -f /home/ben/tmp/thuisserver-ransom.txt ]; then
  echo;
  echo "CONFLICT!";
  echo "Thuisserver-Backup is bezig, nu geen Images-Backup";
  sleep 10;
  exit;
fi

# Check of Testserver-Backup draait, zo ja dan mag Images-Backup niet starten!
if [ -f /home/ben/tmp/testserver-ransom.txt ]; then
  echo;
  echo "CONFLICT!";
  echo "Testserver-Backup is bezig, nu geen Images-Backup";
  sleep 10;
  exit;
fi

Met bovenstaande code wordt gecheckt of er een ander proces actief is.
Het script 'thuisserver-backup start dagelijks om 12:05 uur. In het thuisserver-backup- en het images-backup script wordt aan het begin een zgn controle bestand geladen in /home/ben/tmp.

Zolang 'thuisserver-backup' of 'testserver-backup' draait is dit het bestand /home/ben/tmp/xxxserver-ransom.txt
Om een conflict te voorkomen wordt daarom dit script 'images-backup' afgebroken als er een bestand /home/ben/tmp/xxxserver-ransom.txt bestaat.
De backupserver wordt niet gestopt , het script 'xxxserver-backup' is immers nog bezig!

Wek Admin-PC

# Wek ben-pc
echo "  Wekken en verbinding maken met ben-pc.....";
/usr/local/bin/wakeup -c1 -w5 ben-pc
if [ $? -ne 0 ]; then
  # echo "geen verbinding met host";
  # echo "error mail"
  cat /home/ben/geen-connectie-mail.txt | msmtp ben@makkink.eu;
  halt;
  exit;
fi

Voor deze Backup moet verbinding gemaakt worden met de Admin-PC, maar deze staat mogelijk in de slaapstand.
Met het script 'wakeup' halen we de Admin-PC uit de slaapstand.

Als er geen verbinding tot stand komt, dan wordt een e-mail naar Admin gestuurd en wordt verdere uitvoeringvan het 'images-backup' script gecanceld en de Backup-Server afgesloten ('halt').
Zie voor msmpt Backup Server::Configureren MSMTP e-mail van commandline
Zie voor inhoud e-mail: /home/ben/geen-connectie-mail.txt

Naar index

# Per default is de externe backup drive niet gekoppeld, maar we controleren het toch nog even
# een keer voordat we de airgap sluiten 
if mountpoint -q "/store"; then
   umount -l /store;
   wait;
   echo "  De backup drive was nog gemount en is nu ontkoppeld";
fi

De externe backup drive is normaal niet gekoppeld om de airgap in stand te houden.
En na elke mount voor synchronisatie wordt de SSD opnieuw ontkoppeld. Maar bijv. door een crash van het programma kan het gebeuren dat de SSD nog gekoppeld is.
We willen voordat er verbinding met de mainserver gemaakt wordt, zeker stellen dat de SSD niet gekoppeld is.

Als mountpount '/store' bestaat verwijderen we deze.

# Verwijder mogelijk nog achtergebleven controlebestand /home/ben/tmp/pcs-ransom.txt
  rm -rf /home/ben/tmp/pcs-ransom.txt;

# check of op BEN-PC het controle bestand bestaat en niet encrypted is.
 sshpass -f ~/.rsync_pass_ben-pc rsync -azh backuprsyncd@192.168.178.2::Images/*txt /home/ben/tmp/

if [ -f /home/ben/tmp/pcs-ransom.txt ]; then
    if grep -q "\bransomware-check\b" /home/ben/tmp/pcs-ransom.txt; then

Om vast te stellen dat de mainserver geen ransomware bevat is op de Admin-PC in de map 'Images' een z.g.n. controletekstbestand 'pcs-ransom.txt' geplaatst.

Voordat we dit bestand downloaden maken we zeker dat er geen oud controlebestand achtergebleven is:
rm -rf /home/ben/tmp/pcs-ransom.txt;

Vervolgens wordt, indien het bestand nog bestaat op de Admin-PC, gedownload naar /home/ben/tmp
sshpass -f ~/.rsync_pass_ben-pc rsync -azh --exclude '*/' root@192.168.178.2::Images/* /home/ben/tmp/;
Zie voor rsync met sshpass: Backup Server::Configureren SSH

Indien het bestand bestaat en gedownload kan worden wordt gecontroleerd of het bestand leesbaar is door te zoeken naar een exact woord.
if grep -q "\bransomware-check\b" /home/ben/tmp/pcs-ransom.txt
Als dit niet het geval is dan gaan we er van uit dat de Admin-PC met ransomware besmet is en we beindigen het process

if [ -f /home/ben/tmp/pcs-ransom.txt ]; then
    if grep -q "\bransomware-check\b" /home/ben/tmp/pcs-ransom.txt; then

       # Het controle-bestand in //ben-pc/Images is in orde.
       # Het is veilig de externe Backupdrive te koppelen voor synchronisatie.
       echo "  Het controlebestand op Ben-PC is in orde, mounting SSD....";
       mount UUID=138d237d-dae1-4c0f-8246-b766b1d33737 /store;
       wait;
       echo "  Start Rsync naar BackupServer van:";
       echo "  ----------------------------------";
       echo;
       echo "Ben-PC";
       echo "------";    
        # synchroniseer alleen maandelijkse full backups
        sshpass -f ~/.rsync_pass_ben-pc rsync -av backuprsyncd@192.168.178.2::Images/ben-pc/*benpc-00-00.mrimg /store/pc-images/ben-pc;
       wait;
       # Bewaar alleen de laatste backups
       # Bewaar 3: tail -n +4
       # Bewaar 2: tail -n +3
       # Bewaar 1: tail -n +2
       ls -t /store/pc-images/ben-pc | tail -n +3 |xargs rm -f --;
       echo;
       echo "Benovo";
       echo "------";
        sshpass -f ~/.rsync_pass_ben-pc rsync -av --delete backuprsyncd@192.168.178.2::Images/*benovo-00-00.mrimg /store/pc-images;
       echo;
       echo "Erica";
       echo "-----";
        sshpass -f ~/.rsync_pass_ben-pc rsync -av --delete backuprsyncd@192.168.178.2::Images/*erica-00-00.mrimg /store/pc-images;
       echo;
       echo "BackupServer";
       echo "------------";
        sshpass -f ~/.rsync_pass_ben-pc rsync -av --delete backuprsyncd@192.168.178.2::Images/raspberry* /store/pc-images;
       wait;
       echo;
       echo "  Einde Rsync van PC's naar BackupServer";
       echo "  ----------------------------------------"; 

       # Na de synchronisatie ontkoppelen we de externe drive
       umount -l /store;
       wait;
       echo;
       echo "  Einde Rsync en SSD ontkoppeld: "$(date +%d/%m/%Y-%X);
       echo "  ===================================================";
       # Stop timer
       einde=$(date +"%s");
       DIFF=$(($einde-$begin));
       echo "  Duur backup: $(($DIFF / 3600 )) uur $((($DIFF % 3600) / 60)) minuten $(($DIFF % 60)) seconden.";
       echo;
       sleep 5;
       # Verwijder controlebestand /home/ben/tmp/pcs-ransom.txt
       rm -rf /home/ben/tmp/pcs-ransom.txt;
       # Shutdown Backup-Server
       halt;
       exit;
    fi
   # echo "Ben-pc ransomed?";
fi

Naar index

Als het controle bestand in orde is:

1. Wordt de SSD gekoppeld: mount UUID=105c8fa8-a129-4029-bdc8-badce75915b1 /store;
   Zie ook Backup Server::Configureren Mount externe USB-SSD
    
2. Synchroniseer Images naar Backup-Server
   Ben-pc
   sshpass -f ~/.rsync_pass_ben-pc rsync -av backuprsyncd@192.168.178.2::Images/ben-pc/*benpc-00-00.mrimg /store/pc-images/ben-pc;
   Omdat we alleen de maandelijkse full backup willen synchroniseren kiezen we de bestanden met 00-00.mrimg aan het eind.
   Door deze extra filter werkt de --delete optie niet en loopt het aantal backups op.
   We willen alleen de laatste 2 behouden en verwijderen we de rest
   ls -t /store/pc-images/ben-pc | tail -n +3 |xargs rm -f --;
   Benovo laptop
   sshpass -f ~/.rsync_pass_ben-pc rsync -av --delete backuprsyncd@192.168.178.2::Images/benovo/ /store/pc-images/benovo;
   Erica laptop
   sshpass -f ~/.rsync_pass_ben-pc rsync -av --delete backuprsyncd@192.168.178.2::Images/erica/ /store/pc-images/erica;
   Backup-Server
   sshpass -f ~/.rsync_pass_ben-pc rsync -av --delete backuprsyncd@192.168.178.2::Images/raspberry/ /store/pc-images/raspberry;
    
3. Ontkoppel de SSD
   umount -l /store;
    
4. Nu wordt de eindtijd weergegeven voor in de log.
   $(date +%d/%m/%Y-%X)
    
5. De eindtijd wordt opgeslagen in de variabele 'einde' om vervolgens de duur van de backup te bereken en weer te geven..
   einde=$(date +"%s");
   DIFF=$(($einde-$begin));
   echo " Duur backup: $(($DIFF / 3600 )) uur $((($DIFF % 3600) / 60)) minuten $(($DIFF % 60)) seconden."
    
6. Het controlebestand wordt nu verwijderd en is daarme tevens indicatie dat het proces afgerond is.
   rm -rf /home/ben/tmp/pcs-ransom.txt;
    
7. De Images-backup is nu afgerond en de Backup-Server wordt nu afgesloten.
   halt;
   exit;
   Het commando 'shutdown now' heeft enige tijd nodig en om te voorkomen dat het script nog verder uitgevoerd wordt voordat de shutdown compleet is onderbreken we het script met 'exit'

Naar index

Exit Ransom

# Het controlebestand //ben-pc/Images/pcs-ransom.txt bestaat niet of is versleuteld. Potentieel ransomware!
 echo;
 echo "  Ben-pc is waarschijnlijk geransomed. Een error-mail is verstuurd.";
cat /home/ben/pcs-ransom-mail.txt | msmtp ben@makkink.eu;
echo;
echo "  Shutdown BackupServer";
sleep 5;
shutdown now; 

Als het controlebestand niet bestaat en/of niet leesbaar is waarschuwen we de Admin met een e-mail
cat /home/ben/pcs-ransom-mail.txt | msmtp ben@makkink.eu;

Zie voor msmpt Backup Server::Configureren MSMTP e-mail van commandline
Zie voor inhoud e-mail: /home/ben/pcs-ransom-mail.txt

Als laatst wordt de Backup-Server afgesloten
halt;

Naar index

Pi-Sysback

Van het Raspberry Pi OS op de SD kaart wordt geregeld handmatig een Image gemaakt. Dit doen we in ieder geval elke keer voordat er wijzigingen/upgrades aangebracht gaan worden en vervolgens opnieuw als alles na de wijzigingen goed werkt. Deze Images worden in eerste instantie opgeslagen op de Admin-PC in de map /Images en op de hand weggeschreven naar de BackupServer.

Herstel van een 'defecte' OS met een image houdt in dat de gehele OS op de SD-kaart teruggezet/vervangen wordt.
Dit is soms teveel van het goede en is het effectiever alleen een corrupt bestand te vervangen.
Om dit te kunnen doen maken we naast de Image backup ook een tarball van het complete OS en slaan deze op op de SSD.

Geen CRON voor Pi-Sysback
Voor dit script maken we geen cron en voeren we het handmatig uit naar behoefte, d.w.z. voor en na een grote bewerking van het OS.

Belangrijk: Maak elke keer vóórdat we updates/wijzigingen aanbrengen in het OS van de Backup Server eerst een PI-Sysback tarball

Script pi-sysback stap voor stap
Bekijk hier het complete script.

Het process stap voor stap:

#!/bin/bash
#**************************************************************************************
#*  PI-SYSBACK script version 1.0  Voor BACKUPSERVER.         Ben Makkink 16/08/2024  *
#**************************************************************************************
#*  Eenvoudig programma om het OS van de backup-server als backup op te slaan         *
#*  Het script wordt alleen handmatig uitgevoerd op momenten die daarom vragen, zoals"*
#*  voordat er aan programa's gesleuteld wordt. De tarball wordt opgeslagen in        *
#*  /store/pi-sysback. Zie aan het eind de restore informatie                         *
#**************************************************************************************

# Check of SSD al is gekoppeld
echo;
if mountpoint -q "/store"; then
  echo "   SSD is al gemount";
else
  echo "   Mounting SSD....";
  mount UUID=138d237d-dae1-4c0f-8246-b766b1d33737 /store;
  wait;

De tarball willen we wegschrijven naar de SSD, als dit nog niet zo is dan wordt de SSD gekoppeld.

Naar index

echo "  Start Pi-sysback";
echo "  ----------------";

# Plaats jezelf in de root
cd /;

# Set VARIABLES
# Geef hier aan waar backups opgeslagen moeten worden
sysbackdir="/store/pi-sysback/";

# Geef hier aan welk datumformaat gebruikt moet worden voor de bestandsnaam van de backup
datestamp=$(date +%Y%m%d)

# Maak tarball van systeem bestanden
tar -cvzf $sysbackdir$datestamp"-pi-sysback.tar.gz" --exclude /proc --exclude /sys --exclude /store /;
wait;

De tarball die we maken moet vanuit de root van het OS
# Plaats jezelf in de root
cd /;

Zet enkele variabelen
# Geef hier aan waar backups opgeslagen moeten worden
sysbackdir="/store/pi-sysback/";

# Geef hier aan welk datumformaat gebruikt moet worden voor de bestandsnaam van de backup
datestamp=$(date +%Y%m%d)

Maak de tarball van het complete OS "/", behalve de mappen /proc, /sys, en /store
tar -cvzf $sysbackdir$datestamp"-pi-sysback.tar.gz" --exclude /proc --exclude /sys --exclude /store /;
Wacht totdat de tarball klaar is voor verder te gaan met het script
wait;

Naar index

# delete bestaande tarballs, bewaar 2 laatste
# Bewaar alleen de laatste tarballs
# Bewaar 3: tail -n +4
# Bewaar 2: tail -n +3
# Bewaar 1: tail -n +2
cd $sysbackdir;
ls -t | tail -n +3 |xargs rm -f --;

Plaats jezelf in $sysbackdir (/store/pi-sysback).
cd $sysbackdir;

Delete oude tarballs, bewaar alleen de laatste twee tarballs.
ls -t | tail -n +3 | xargs rm -f --;

# Check of SSD ontkoppeld mag worden, i.e. er is geen mainserver- of images-backup gaande?
if [ -f /home/ben/tmp/*-ransom.txt ]; then
        echo;
        echo "  De SSD is niet ontkoppeld, er is nog een backup actief";
        sleep 5;
        exit;
fi

# Als er geen ander proces gebruikt maakt van de SSD dan kan deze ontkoppeld worden
  umount -l /store;
  wait;
  echo;
  echo "  De SSD is succesvol ontkoppeld";
  sleep 5;

Als de xxxserver-backup draait dan staat er in /home/ben/tmp het controlebestand xxxserver-ransom.txt
Als de images-backup draait dan staat er in /home/ben/tmp het controlebestand pcs-ransom.txt
Als dus 1 van de 2 bestanden aanwezig is dan loopt er nog een backup en mag de SSD dus niet ontkoppeld worden

if [ -f /home/ben/tmp/*-ransom.txt ]; then
   echo; echo " De SSD is niet ontkoppeld, er is nog een backup actief";
   sleep 5;
   exit;
fi

Als er geen ander process gebruik maakt van de SSD dan wort deze ontkoppeld.
umount -l /store;

Naar index

Restore informatie
Aan het einde van het script staat nog uitgebreide informatie hoe een restore uitgevoerd kan worden met de data in de tarball.

# ===========================================================================================
# RESTORE PI-SERVER met (secties uit) tarball samengesteld met script PI- SYSBACK
# ===========================================================================================
# Sysback v1.0 16 augustus 2024 Ben Makkink
# -------------------------------------------------------------------------------------------
# 1. Bestanden (tarballs) zijn opgeslagen in /store/pi-sysback
# 2. Tarballs zijn gecreeerd met path vanuit root '/'
# 3. !!! Dus extract (restore) uitvoeren vanuit root '/' !!!
#
# Hier een voorbeeld met een backup met naam: 20151025-pi-sysback.tar.gz
# Gebruik volgende commando's:
# #cd /                                                         (extract tarball vanuit root)
# #ls /store/pi-sysback                                   (haal lijst met bestaande tarballs)
# #tar -tzvf /store/pi-sysback/20151025-pi-sysback.tar.gz(lijst van bestanden in een tarball)
# voorbeeld: usr
#            usr/lib64/security/
#            usr/lib64/security/pam_chroot.so
#            etc.
# #tar -tzvf /store/pi-sysback/20151025-pi-sysback.tar.gz usr/local/bin
# toont lijst van bestanden onder usr/local/bin in de tarball
#
# #tar -xzvf /store/pi-sysback/20151025-pi-sysback.tar.gz
#                              (restore complete '/' directory en subdirectories)
# #tar -xzvf /store/pi-sysback/20151025-pi-sysback.tar.gz usr
#                              (restore alleen subdir 'usr' en al z'n subdirectories)
# #tar -xzvf /store/pi-sysback/20151025-pi-sysback.tar.gz usr/local/bin/sysback
#                              (restore alleen bestand 'sysback')
#
# Als bijvoorbeeld met het laatste voorbeeld de fout gemaakt wordt dit commando niet vanuit
# / (root) te geven maar vanuit /home dan belandt het uitgepakte bestand op
# /home/usr/local/bin/sysback. Dus een hele nieuwe reeks met (sub)dirs op de verkeerde plaats.
#
# Opties van commando tar:
# -c creeer,  -t list,  -x extract, -z zip/unzip naar/van gz,  -v verbose
# -f onmiddellijk gevolgt door de tarball naam.
# ===========================================================================================

Naar index

Restore met Backup-Server backups

Hieronder de verschillende opties van herstel met de data opgeslagen op de Backup-Server

Restore Backup-Server-OS

De opties wanneer er zich problemen voordoen met de Backup-Server zelf

1. De Backup-Server start wel op maar er zijn bijvoorbeeld bestanden corrupt en/of per abuis verwijderd:
   - Mount de SSD en zie opties zoals hierboven beschreven.
    
2. De Backup-Server start helemaal niet meer op:
   - Restore Raspberry Pi SD-kaart met Image op Admin-PC. Zie OS Backup-image
    
3. Als Backup-Server niet opstart en de image op de Admin-PC niet meer bestaat of corrupt is (ransomed):
   - Mount de Backup-Server SSD op een andere Linux machine (mainserver/homeserver).
   - Op de Server:
      Mount de Backup-Server SSD
      Kopieer van SSD/pc-images de raspberry_light_backup_xx-xx-xxxx.img bestanden naar een Samba share op de server bijv. /home/files.
   - Op een Windows-PC:
      Kopiëer de Raspberry image(s) en Restore Raspberry Pi SD-kaart als in punt 2

Naar index

Restore Thuisserver-Ubuntu OS

Als van de Thuisserver een root map beschadigd of verwijderd is kan in veel gevallen het systeem niet meer opstarten.
In zo'n geval moeten we de machine booten met de installatie disk.
Zie Herstel met backups en boot met rescue disk

Als op de Homeserver het Sysback bestand in /vault/sysback niet meer bestaat of corrupt is (ransomed), kunnen we een Sysbackbestand gebruiken dat opgeslagen is op de Backup-Server

Procedure van het restoren van de Thuisserver met een Sysbackbestand op de Backup-Server

NOTE:
Als we niet zeker zijn dat de Homeserver clean is sluit dan de Backup-Server SSD nooit aan, maar maak eerst op de Backup-Server een kopie van de benodigde bestanden op een USB-drive

Start de Thuisserver met monitor en de installatiedisk Ubuntu Server

1. Selecteer Troubleshooting en vervolgens 'Rescue' en vervolgens het systeem laten proberen de systeemimage op /mnt/sysimage te laten zetten.
2. Als dit lukt dan worden 4 opties geboden, kies 1 - Continue en volg instructies: Press Return naar Shell en geef commando chroot /mnt/sysimage.
   Start het OS in Rescue Mode als de Installatiedisk het systeem niet kan mounten op /mnt/sysimage
   vervolg
3. # lsblk voor een listing van de devices aangesloten op de Thuisserver
4. Sluit de externe USB SSD aan op de Thuisserver. Zie NOTE
5. Voer nu opnieuw # lsblk uit en vind het nieuw aangesloten device bijv. sdf1
6. # mkdir /mnt/ssd
7. # mount -t ext4 /dev/sdf1 /mnt/ssd
8. # ls -l /mnt/ssd/vault/sysback
   Geeft listing met de meest recente sysback tarballs bijv. 20161099-sysback.tar.gz op de Backup-Server SSD
9. # cd / 
   Plaats je zelf in de Thuisserver root
10. # tar -xzvf /mnt/ssd/vault/sysback/20161099-sysback.tar.gz /boot
    Hiermee wordt /boot op de Thuisserver teruggezet met de backup
    Zie ook het document 'sysback_restore_readme' met restore-gebruikersinstructies

Kopie van Backup-Server Backup maken

1. Start Backup-Server, start script 'utils' en mount SSD
2. # lsblk voor een listing van de aangesloten devices
3. Sluit een tweede externe USB device aan
4. Voer nu opnieuw # lsblk uit en vind het nieuw aangesloten device bijv. sdb1
5. Indien nog niet gebeurd > Maak partitie op sdb1 en formatteer ext4. Zie Opslagmedium toevoegen
6. # sudo mkdir /mnt/doel
7. # sudo mount -t ext4 /dev/sdb1 /mnt/doel
8. # sudo cp -a /store/vault /mnt/doel of bijvoorbeeld # sudo cp -a /store/vault/backuppc/ben-pc.236.tar.gz /mnt/doel
9. Plug nu de kopie in op de thuisserver en vervolg bovenstaand schema met punt 6

Naar index

Restore Server-DATA

Van alle data op de Server (Live en Backup) is een backup opgeslagen op een physiek gescheiden disk van de Server: /vault
Zie Thuisserver Backup Flowchart

Alle data van alle machines in het thuisnetwerk zijn te restoren met de backups in /vault

Op de Backup-Server staat een copie van deze vault.
In het geval dat de Thuisserver/vault disk niet meer beschikbaar is en/of geransomed, dan kunnen we de backup op de Backup-Server gebruiken.

Restore Thuisserver-Data met Backup-Server

De meest simpele methode is d.m.v. het aansluiten van de Backup-Server SSD of beter een kopie (Zie NOTE) op de Server en deze vervolgens te mounten.
Nu kunnen we alle benodigde data kopieren naar Server/vault of direct naar de betreffende Live- en/of Backup Data

Naar index

Restore Windows PC

OS-Images

Alle Macrium Reflect OS-images van de Windows PC's in het thuisnetwerk zijn opgeslagen op een externe USB drive en op de Admin-PC.

Restore OS met Image
Bij een restore van een Windows PC starten we de PC met de Macrium bootdisk en zetten de image terug met een kopie van de image op een externe USB drive.
Mocht de image op de Admin-PC of de externe USB drive niet (meer) beschikbaar zijn of corrupt dan kunnen we de backup op de Backup-Server gebruiken.

Restore PC met image op de Backup Server

A. Via thuisnetwerk
    Alleen als er geen risico bestaat op ransomware besmetting!

1. Start Backup-Server, start script 'utils' en start Samba-Share
2. # ls -l /store/pc-images
   Geeft listing met de meest recente images bijv. 08BA942628C46B3E-benpc-00-00.mrimg voor de Admin-PC
3. # sudo cp -a /store/pc-images/08BA942628C46B3E-benpc-00-00.mrimg /store/share
   Kopieert de image naar de Samba-Share. De image is nu beschikbaar op het netwerk.
4. Start Windows PC met Macrium Reflect bootdisk
5. Ga naar > 'Overige Taken' > 'Netwerk Configureren'
   Selecteer beschikbare Wifi verbinding en verbind.
6. Selecteer > 'Naar een imagebestand bladeren' en klik op Netwerk Symbool
7. Wijs Netwerkschijf toe:
   Share: \\192.168.178.10\share
   Gebruikersnaam: pi-samba
   Wachtwoord: zie Lastpass
   Dubbleklik op geselecteerde pi-samba netwerkschijf
   Selecteer gewenste Image en OK
8. In Homescherm klik op 'Terugzetten'
9. Zodra restore succesvol: Sluit Samba-Share op de Backup-Server

B. Met externe USB NTFS disk met Images van de Backup-Server

1. Start Backup-Server, start script 'utils' en mount SSD
2. # lsblk voor een listing van de aangesloten devices
3. Sluit de externe USB PC Images-disk (NTFS) aan.
4. Voer nu opnieuw # lsblk uit en vind het nieuw aangesloten device bijv. sdb1
5. # sudo mkdir /mnt/doel
6. # sudo mount -t ntfs-3g /dev/sdb1 /mnt/doel
7. # ls -l /store/pc-images
   Geeft listing met de meest recente images bijv. 08BA942628C46B3E-benpc-00-00.mrimg voor de Admin-PC
8. # sudo cp -a /store/pc-images/08BA942628C46B3E-benpc-00-00.mrimg /mnt/doel
   Dit kopieert de image van benpc naar de externe images drive
9. Start op Benpc Macrium Reflect met bootdisk en gebruik de image op de externe Images drive voor restore.

Window-PCs-Data

Van alle Windows PC's worden dagelijks backups van de Data gemaakt door BackupPC op de Mainserver. Zie Backup Flowchart
De Data op de diverse PC's zijn te restoren dmv downloads door de Thuisserver App BackupPC of downloads van tarballs uit de 2e backup in /vault/backuppc

Mochten de Thuisserver Backups en/of de tarballs in de /vault niet (meer) beschikbaar zijn of corrupt dan kunnen we de backup op de Backup-Server gebruiken.
Deze data bieden we dan aan in de Samba-Share van de Backup-Server

Voorbeeld van Data Restore van Benovo Laptop met Backup-Server

1. Start Backup-Server, start script 'utils' en start Samba-Share
2. # ls -l /store/vault/backuppc
   Geeft listing met de meest recente tarballs bijv. benovo.409.tar.gz
3. # cd /store/share
4. ben@pi-nas:/store/share $ sudo tar -xvzf /store/vault/backuppc/benovo.409.tar.gz .
   Extraheert tarball in /store/share
5. Open op Benovo laptop de Verkenner en navigeer naar \\pi-nas\share
6. Kopieer alle of alleen de gewenste data naar de laptop.

Naar index