Archive for the ‘Backups’ Category

Build a Central Linux Logging Server to Collect, Store, and Visualize All Infrastructure node Logs

Friday, March 20th, 2026

build-a-central-linux-logging-server-to-collect-store-and-visualize-all-infrastructure-node-logs
If you manage multiple servers or collection of multiple services on many nodes within a company server infrastructure, you know the pain of dealing with logs scattered to multiple locations across systems. It is really crazy and takes up a lot of time and drains energy.
One server shows nothing, another rotated logs yesterday, and your app logs are buried somewhere in /var/log/app.

A central logging server solves this problem, as all logs collected, stored, and accessible in one single place.

In this article will present shortly how to build one using ELK Stack + Beats (lightweight agents) on a Linux server.

1. Architecture Overview

Here’s the typical flow looks like this:

[ Servers / Apps ] –> [ Filebeat / Metricbeat ] –> [ Logstash ] –> [ Elasticsearch ] –> [ Kibana / Grafana (Visualization) ]

  • Beats → Lightweight log shippers installed on all machines.
  • Logstash → Optional pipeline for parsing, filtering, and enriching logs.
  • Elasticsearch → Storage and search engine.
  • Kibana / Grafana → Visualization dashboards.

2. Prepare Your Central Logging Server

Requirements:

  • Debian Linux 12 recommended / Ubuntu or Fedora RHEL
  • At least 4 GB RAM (8+ GB for production ELK)
  • Plan enough SSD storage (logs grow fast)
  • Open ports: 5044 for Beats, 9200 for Elasticsearch, 5601 for Kibana

Install Prerequisites

# apt update && sudo apt install openjdk-17-jdk wget curl apt-transport-https -y

ELK requires Java, OpenJDK 17 should work fine.

3. Install Elasticsearch

# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.11.1-amd64.deb
# dpkg -i elasticsearch-8.11.1-amd64.deb
# systemctl enable elasticsearch
# systemctl start elasticsearch


Check ElasticSearch server is running:

# curl -X GET "localhost:9200/"

That should see the Cluster info in JSON format.

4. Install Kibana

# wget https://artifacts.elastic.co/downloads/kibana/kibana-8.11.1-amd64.deb
# dpkg -i kibana-8.11.1-amd64.deb
# systemctl enable kibana
# systemctl start kibana


Access Kibana URL in browser:

http://<server-ip>:5601

5. Install Logstash to Process logs before sending to Elasticserch

# wget https://artifacts.elastic.co/downloads/logstash/logstash-8.11.1.deb
# dpkg -i logstash-8.11.1.deb
# systemctl enable logstash
# systemctl start logstash

Logstash allows filtering and structuring logs before sending them to Elasticsearch. Example simple pipeline:

# vim /etc/logstash/conf.d/syslog.conf

input {
  beats {
    port => 5044
  }
}
filter {
  grok { match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:host} %{DATA:program}: %{GREEDYDATA:message}" } }
}
output {
  elasticsearch {
    hosts => [“localhost:9200”]
    index => "central-logs-%{+YYYY.MM.dd}"
  }
}

Start Logstash

# systemctl restart logstash

6. Install Beats on Client Machines

On each server you want to monitor:

# apt install filebeat metricbeat -y


Configure Filebeat

Edit config

# vim  /etc/filebeat/filebeat.yml

Set the output to your central server:

output.logstash:

hosts: [":5044"]

Start the agent:

systemctl enable filebeat
systemctl start filebeat

Do the same for Metricbeat if you want metrics like CPU, memory, disk.

7. Create Dashboards in Kibana or Grafana

  • In Kibana, use Discover to view logs.
  • Create visualizations for errors, warnings, top endpoints, etc.
  • Use Grafana if you want multi-source dashboards, combining logs and metrics.

8. Optional: Secure Your Logging Server

  • Enable TLS/SSL in Beats and Elasticsearch.
  • Use firewall rules to restrict access.
  • Create dedicated users in Elasticsearch for log access.

9. Maintenance Tips

  • Index Lifecycle Management → Rotate daily and delete old logs automatically.
  • Monitor disk usage → Logs grow fast. SSDs are better.
  • Filter noise → Don’t ship debug logs unless needed.
  • Backup Elasticsearch → Especially if logs are critical.

Sum Up, how it Works

  • All logs are centralized → easier troubleshooting.
  • Scalable → add new servers, Beats handle shipping automatically.
  • Searchable → find errors instantly using Elasticsearch.
  • Visual → dashboards in Kibana/Grafana give real-time insight.

How to Make Easy Backups on Linux Using a GUI tools Deja Dup, TimeShift, BackinTime, Grsync, Vorta

Monday, February 2nd, 2026

Backing up your data on Linux doesn’t have to involve complex terminal commands or custom scripts. While the command line is powerful, many users prefer a simple graphical interface (GUI) that just works.

Luckily, Linux offers several excellent GUI-based backup tools that are easy, reliable, and beginner-friendly.

In this article, we’ll look at why backups matter, and then walk through some of the best GUI backup tools for Linux, along with basic setup tips.

Why Backups Are Important (Even on Linux)

Linux systems are known for stability, but unfortunately, no system is immune to:

  • Hard drive failures
  • Accidental file deletion
  • System updates gone wrong
  • Malware or ransomware
  • Laptop theft or damage

A proper backup ensures you can restore your files or even your entire system in minutes instead of losing everything.

What Makes a Good GUI Backup Tool?

For most desktop users, a good backup tool should :

  • Be easy to use (no terminal required)
  • Supports automatic scheduled backups
  • Allow restoring individual files
  • Work with different types of external drives or network storage
  • Be relatively actively maintained
     

Let’s look at the few tools to create backups with lesser effort.

1. Déjà Dup – The Simplest Backup Tool

Best for: Beginners and home users
Available on: Ubuntu, Linux Mint, Fedora, and others

Déjà Dup is one of the most user-friendly backup tools on Linux. It comes preinstalled on Ubuntu and integrates perfectly with the GNOME desktop.

Key Features

  • Very simple interface
  • Automatic scheduled backups
  • Supports local drives, external USB disks, and network locations
  • Optional encryption for security

# apt info deja-dup
Package: deja-dup
Version: 44.0-2
Priority: optional
Section: utils
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Installed-Size: 4,851 kB
Depends: duplicity (>= 0.7.14), dconf-gsettings-backend | gsettings-backend, libadwaita-1-0 (>= 1.2), libc6 (>= 2.34), libglib2.0-0 (>= 2.70.0), libgpg-error0 (>= 1.14), libgtk-4-1 (>= 4.0.0), libjson-glib-1.0-0 (>= 1.5.2), libpackagekit-glib2-18 (>= 1.1.0), libpango-1.0-0 (>= 1.18.0), libsecret-1-0 (>= 0.18.6), libsoup-3.0-0 (>= 3.0.3)
Recommends: gvfs-backends, packagekit, policykit-1
Suggests: python3-pydrive2
Homepage: https://launchpad.net/deja-dup
Tag: admin::backup, implemented-in::c, interface::graphical, interface::x11,
 role::program, scope::application, suite::gnome, uitoolkit::gtk,
 x11::application
Download-Size: 693 kB
APT-Sources: http://ftp.debian.org/debian bookworm/main amd64 Packages
Description: Backup utility
 Déjà Dup is a simple backup tool. It hides the complexity of backing up the
 Right Way (encrypted, off-site, and regular) and uses duplicity as the
 backend.
 .
 Features:
  * Support for local, remote, or cloud backup locations such as Nextcloud
  * Securely encrypts and compresses your data
  * Incrementally backs up, letting you restore from any particular backup
  * Schedules regular backups
  * Integrates well into your GNOME desktop

How to Use Déjà Dup

Using it is generally simplistic, you select the data folders to be backupped and then the media where to backup it. The program supports also encryption with a password which is nice if you want to keep the backed-up data secret (especially if you want to store the backup on Google Cloud or Microsoft Azure)

Open “Backups” from your application menu

  1. Choose folders to back up (e.g., Home folder)
  2. Select a backup location (external drive recommended)
  3. Enable automatic backups


Click on Back Up Now button

That’s it. Déjà Dup runs quietly in the background after setup.

Note ! that it is not a good idea to try to backup the whole Linux installation ! with deja-dup, as you will get a lot of issues with improper permissions errors and stuff and the OS backup won't get consistent, however for a basic backups of User Homes, Cictures and some Personal data situated within a single directory it is simple as it is easy to initially setup and run.

# apt install deja-dup

$ sudo deja-dup

 

deja-dup-backup-gui-tool-linux-screenshot

deja-dup-backup-gui-tool-linux-screenshot2

2. Timeshift – System Snapshots Made Easy

Best for: System recovery
Available on: Most Linux distributions

Timeshift focuses on system backups, not personal files. It creates restore points similar to Windows System Restore.

Key Features

  • Snapshot-based backups
  • Perfect for rolling back failed updates
  • Supports RSYNC and BTRFS
  • Clean and simple GUI
     

When to Use Timeshift

  • Before major system updates
  • After fresh OS installation
  • To recover from broken packages or configs

# apt info timeshift
Package: timeshift
Version: 22.11.2-1+deb12u1
Priority: optional
Section: utils
Maintainer: Yanhao Mo <yanhaocs@gmail.com>
Installed-Size: 3,231 kB
Depends: cron-daemon | cron, pkexec, psmisc, rsync, libc6 (>= 2.34), libcairo2 (>= 1.2.4), libgdk-pixbuf-2.0-0 (>= 2.22.0), libgee-0.8-2 (>= 0.8.3), libglib2.0-0 (>= 2.39.4), libgtk-3-0 (>= 3.16.2), libjson-glib-1.0-0 (>= 1.5.2), libvte-2.91-0, libxapp1 (>= 1.0.4)
Breaks: util-linux (<< 2.37.2~)
Replaces: timeshift-btrfs
Homepage: https://github.com/linuxmint/timeshift
Tag: uitoolkit::gtk
Download-Size: 617 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.debian.org/debian bookworm/main amd64 Packages
Description: System restore utility
 Timeshift is a system restore utility which takes snapshots
 of the system at regular intervals. These snapshots can be restored
 at a later date to undo system changes. Creates incremental snapshots
 using rsync or BTRFS snapshots using BTRFS tools.

# apt install timeshift

$ sudo timeshift-gtk

 

https://www.pc-freak.net/images/linux-gui-backup-tools-screenshot/timeshift-rsync-backup-gui-tool-linux-screenshot4

timeshift-rsync-backup-gui-tool-linux-screenshot5

timeshift-rsync-backup-gui-tool-linux-screenshot6

3. Use Timeshift alongside a file backup tool like Déjà Dup as a backup solution for OS and data

a. Set up Timeshift (system snapshots)

What to include

Snapshot type:

  • RSYNC → works on any filesystem (recommended)
  • BTRFS → if your root is BTRFS


timeshift-rsync-backup-gui-tool-linux-screenshot1

Include:

  • / (root filesystem)

Exclude home directories (important!)

In Timeshift settings:

  • Keep /root excluded
  • Do NOT include /home/youruser

timeshift-rsync-backup-gui-tool-linux-screenshot2

Timeshift is not meant to back up your personal files.

Schedule (typical)

  • Daily: 3–5 snapshots
  • Weekly: 2–3 snapshots
  • Monthly: optional

Store snapshots on:

A separate drive or partition if possible

b. Set up Deja Dup (personal backups)

Deja Dup is perfect for:

  • Home directory backups
  • Encryption
  • External drives, NAS, cloud (Google Drive, SFTP, etc.)

Folders to back up

Usually:

~/Documents
~/Pictures
(or similar)
Optional: ~/.config (only if you know why)
~/Videos
~/Projects

In Deja Dup:

Folders to back up → select what you actually care about

Folders to ignore → add

~/.cache
~/.local/share/Trash
~/Downloads
(optional)

Schedule

Daily or weekly backup is usually fine

Keep backups for “forever” or at least several months

c. Prevent overlap (this matters)

To avoid wasting space and time:

Tool

Should back up

Should NOT back up

Timeshift

/, system configs

/home

Deja Dup

/home/youruser

/, system files

Never:

  • Use Deja Dup to back up /
  • Use Timeshift to back up /home

That’s the #1 mistake you could do

d. Real-world recovery scenarios

Scenario 1: Bad update / system won’t boot

  1. Boot from live USB

  2. Restore with Timeshift

  3. System is back exactly as before

  4. Files untouched

Scenario 2: Deleted or corrupted files

  1. Open Deja Dup

  2. Restore specific files/folders

  3. Done

Scenario 3: New machine / fresh install

  1. Install OS

  2. Restore system apps/settings manually or via Timeshift (if compatible)

  3. Restore home data with Deja Dup

e. Optional pro tips (to avoid data loss)

  • Test restores once (seriously)
  • Label backup drives clearly
  • Keep Deja Dup backups offsite if possible
  • After major distro upgrades:
  • Make a Timeshift snapshot
  • Don’t restore old Timeshift snapshots across major versions unless you know it’s safe
     

4. Back In Time – More Control features tool to create GUI-Based backups on Linux

Best for: Advanced users who want flexibility

Available on: Most Linux distributions

Back In Time uses RSYNC but wraps it in a friendly GUI.

Key Features

  • Scheduled snapshots
  • Exclude files and folders easily
  • Restore files from any snapshot
  • Supports local and remote backups
     

# apt-cache search backintime


backintime-common – simple backup/snapshot system (common files)
# apt info backintime-qt
Package: backintime-qt
Version: 1.3.3-4
Priority: optional
Section: utils
Source: backintime
Maintainer: Jonathan Wiltshire <jmw@debian.org>
Installed-Size: 416 kB
Depends: backintime-common (= 1.3.3-4), libnotify-bin, pkexec, polkitd, python3-dbus.mainloop.pyqt5, python3-pyqt5, x11-utils, python3:any
Recommends: python3-secretstorage
Suggests: meld | kompare
Conflicts: backintime-kde4
Breaks: backintime-qt4 (<< 1.2.1-0.1~)
Replaces: backintime-kde4, backintime-qt4 (<< 1.2.1-0.1~)
Homepage: https://github.com/bit-team/backintime
Download-Size: 73.8 kB
APT-Sources: http://ftp.debian.org/debian bookworm/main amd64 Packages
Description: simple backup/snapshot system (graphical interface)
 Back In Time is a framework for rsync and cron for the purpose of
 taking snapshots and backups of specified folders. It minimizes disk space use
 by taking a snapshot only if the directory has been changed, and hard links
 for unmodified files if it has. The user can schedule regular backups using
 cron.
 .
 This is the graphical interface for Back In Time.

backintime-qt – simple backup/snapshot system (graphical interface)

# apt install backintime-qt

$ sudo backintime-qt

backintime-linux-backup-gui-easy-tool-screenshot-options

linux-gui-backup-tools-screenshot/backintime-linux-backup-gui-easy-tool-screenshot-options

backintime-linux-screenshot-options-menu

backintime-linux-screenshot-options3

linux-gui-backup-tools-screenshot

It’s slightly more complex than Déjà Dup, but still very manageable.
 

5. Backing Up your Data on Linux with Grsync (rsync GUI frontend backup tool interface)

Grsync is a simple yet powerful graphical tool for backing up data on Linux. It acts as a front-end for rsync, one of the most trusted file synchronization utilities in the Linux world, but removes the need to remember long command-line options. This makes Grsync ideal for users who want reliable backups without extra complexity.

grsync-gui-backup-rsync-tool-linux-screenshot1

With Grsync, you can easily select a source and destination folder, such as backing up your home directory to an external drive or a network location. It supports incremental backups, meaning only changed files are copied after the first run, which saves both time and disk space. Useful options like preserving file permissions, deleting obsolete files, and excluding specific directories (for example, cache or temporary files) can be enabled with simple checkboxes.

Another advantage of Grsync is its safety features. You can perform a dry run to preview what will be copied or deleted before actually starting the backup. This reduces the risk of accidental data loss and makes it easier to fine-tune your backup settings. For Linux users looking for a practical and dependable backup solution, Grsync offers a great balance between power and ease of use.
 

Best Backup Strategy for Desktop Linux Users

For most users, Deja Dup + TimeShift  combo should works perfectly:

  • Déjà Dup → Personal files (documents, photos, videos)
  • Timeshift → System snapshots

This way, you’re protected from both data loss and system failure.

Final Thoughts

Linux gives you freedom – and that includes freedom to choose how you protect your data.

With modern GUI backup tools, there’s no excuse not to back up regularly. Whether you’re a casual user or a hardcore PC freak, setting up backups takes just a few minutes and can save you hours (or days) of frustration later.

If you’re serious about your Linux system data,
backup early, backup often and you this 

will pay you back.

How to Рecover deleted files in windows with Free ( unpaid ) software

Thursday, June 5th, 2025

How to Restore Deleted Files on Windows 10/11 - TinyFrom

It happens sometimes on Windows that accidently you deleted some files or directory with pressing Shift + DELETE key (not sending it to Trashbin) or by deleting fies / dirs by sending them in Trashbin but you decided you want them back once you have cleared up the Trashbin.
If this is the case it is pretty easy  to recover deleted files in Windows using free (freeware) unpaid soft and tools, to do so chooose on of the many options described and follow the some of below methods by the well known and  reputable tools pointed next.

1. Use Recuva (Free Version)

Recuva is one of the most popular free file recovery tools from the makers of CCleaner.

Steps:

  1. Download from the official site: https://www.ccleaner.com/recuva

  2. Install and open Recuva.

  3. Select the type of files you want to recover (e.g., pictures, documents).

  4. Choose the drive where the file was deleted.

  5. Use the Deep Scan option if the regular scan fails.

  6. Select files to recover and save them to a different drive to avoid overwriting.

2. Use PhotoRec (Part of TestDisk)

Despite the name, PhotoRec can recover many types of files, not just photos.

Steps:

  1. Download TestDisk & PhotoRec: https://www.cgsecurity.org/

  2. Extract the archive and run photorec_win.exe.

  3. Select the drive, then the partition.

  4. Choose the file system type (typically "Other").

  5. Select a destination for recovered files on another drive.

  6. Let it scan and recover files.

  7.  

⚠️ PhotoRec runs in a command-line interface but is powerful and completely free.

 

Note that Photorec is also available and can be used on Linux to recover files and if you're used to do things from command line I strongly recommend to give it a try on Windows as well.

3. Windows File History / Previous Versions (If Enabled)

If File History or System Protection was enabled:

Steps:

  1. Right-click the folder where the file was.

  2. Choose Restore previous versions.

  3. Browse previous versions and restore as needed.


4. Windows File Recovery (Microsoft's Free CLI Tool)

A command-line tool from Microsoft for advanced users is avalable it is called winfr

Steps:

  1. Download from Microsoft Store: Windows File Recovery

  2. Open Command Prompt as Administrator.

  3. To recover just a single file use the command:

    C:\>

    winfr C: D: /regular /n \Users\YourName\Documents\file.txt

     

    Replace paths as needed.

  4. To recover a directory it is pretty much the same except you have to include the directory instead of file

C:\> 

winfr C: D: /regular /n \Users\YourName\Documents\YourDeletedFolder\

 

Replace

C:

and

D:

with the appropriate source and destination drives.

 

 

  • C:

    = source drive (where the folder was deleted)

  • D:

    = destination drive (where recovered files will be saved)

  • /n

    = path filter (target folder)

  • /regular

    = mode suitable for NTFS drives


Important Tips:

 

  • Stop using the drive where the file was deleted to avoid overwriting it.
  • Always recover to a different drive.
  • The sooner you act, the higher the recovery success rate.

How to Copy / Backup Windows USB drive from one USB to a second

Friday, October 18th, 2024

Did you know that when you copy all the files from a USB Drive you don’t copy all the data?

Did you know that there may be files that are not even visible?

In this tutorial you will discover how to copy all of your USB Drive sector by sector, that is to say, that you will see how to create a copy identical to your USB drive without missing anything!

This can be useful if you have formatted your USB stick in error and want to use it, you can create an image for the USB Drive on your computer and then you can recover the formatted data in the image afterward!

The software used in this tutorial is called ImageUSB, it is free, portable, and easy to use.

Don’t use this method if you want only to copy some files, use this to clone/backup your USB Drive with all its master boot record, partition tables, and data.

Let’s go!

Clone Your USB Drive with ImageUSB on Windows 10

Start by downloading and extracting ImageUSB from this official URL: https://www.osforensics.com/tools/write-usb-images.html

Double-click on  imageUSB.exe .

Select your USB Drive from the list, select “Create image from USB drive“. Choose the location for the binary image file (.bin) that will be created from the USB drive.

Click on “Create“.Click “Yes” to confirm your choices.

imageusb clone usb flash drive backup restore 3 create image

Click “Yes” to overwrite the bin file in case it’s already there.

Wait for a couple of minutes…

After the image is created you should see this message. Click “OK“.

Now if you want to restore an image to your USB Drive, just select your USB Drive and choose “Write image to USB drive“. Choose your bin image and click on “Write“.

imageusb clone usb flash drive backup restore 7 write

This program is not recommended on different sizes USB Drives…
Use it mostly for backup/restore on the same USB Drive for your bootable software.

There you have it, the copy of USB to second USB completed !

Enjoy ! 

 

 

How to dump and restore Zabbix database to do monitoring database snapshot, PostGreSQL continuous archiving Point in time recovery setup

Monday, November 21st, 2022

postgresql-db-backup-and-continuous-archiving-on-linux-keep-zabbix-backup-regularly

If you have set up a Zabbix server that is using as a database storage postgresql at home or company, then you will need to make sure you don’t loose any data by producing regular postgresql backups. This small article will show how to do the db backup in conventional way with pg_dump / pg_restore as well as how to set the continuous archiving point in time recovery end point recovery so called PITR..
 

1. Connect to the database and some postgres very basics

-bash-4.2$ psql DBNAME USERNAME
 
-bash-4.2$ psql zabbix zabbix
 

After you access a PostgreSQL database, you can run SQL queries and more. Here are some common psql commands:
 
•    To view help for psql commands, type \?.
•    To view help for SQL commands, type \h.
•    To view information about the current database connection, type \conninfo.
•    To list the database's tables and their respective owners, type \dt.
•    To list all of the tables, views, and sequences in the database, type \z.
•    To exit the psql program, type \q.

       Fundamental backup approaches with postgres

As with everything that contains valuable data, PostgreSQL databases should be backed up regularly. While the procedure is essentially simple, it is important to have a clear understanding of the underlying techniques and assumptions.
 
There are three fundamentally different approaches to backing up PostgreSQL data:
 
•    SQL dump
•    File system level backup
•    Continuous archiving

 
Each has its own strengths and weaknesses; each is discussed in turn in the following sections.
 

2.    Creating SQL Dump of postgresql target database

2.1 Manual SQL dump (custom dump format)

 
Use pg_dump's custom dump format. If PostgreSQL was built on a system with the zlib compression library installed, the custom dump format will compress data as it writes it to the output file.
This will produce dump file sizes similar to using gzip, but it has the added advantage that tables can be restored selectively.
The following command dumps a database using the custom dump format:
 

# sudo su – postgres
-bash-4.2% cd  /var/lib/pgsql/9.5/backups/
 
-bash-4.2$  pg_dump -Fc zabbix > /var/lib/pgsql/9.5/backups/zabbixdbdump`date "+%d%m%y%H%M%S"`.gz

2.2 Schedule backups with cron job

To automate the job schedule a cron job to do the work, somethjing like below:
 

# Minute   Hour   Day of Month       Month          Day of Week        Command
# (0-59)  (0-23)     (1-31)    (1-12 or Jan-Dec)  (0-6 or Sun-Sat)

 
@daily  pg_dump -Fc zabbix > /var/lib/pgsql/9.5/backups/Zabbix_db_dump`date "+\%d\%m\%y\%H\%M\%S"`.gz

3. Restore a database from the dump file

3.1. Restoring a database using pg_restore (usually used)

A custom-format dump is not a script for psql, but instead must be restored with pg_restore, for example:
 

# pg_restore -d zabbix /var/lib/pgsql/9.5/backups/Zabbix_db_dump281118151005.gz

3.2. Second Option restoing with psql after creating a restore database

 
# su postgres

-bash-4.2$ psql template1
 
CREATE DATABASE zabbix OWNER zabbix ENCODING 'UTF8';
\q

-bash-4.2$ psql zabbix < /var/lib/pgsql/9.5/backups/zabbixdbdump291117151002.gz
exit

 
NOTE: if you get a permission denied error when trying to restore, check the Unix permissions on the backup file and all the parent directories.

4.    Continuous Archiving and Point-in-Time Recovery (PITR) backups

At all times, PostgreSQL maintains a write ahead log (WAL) in the pg_xlog/ subdirectory of the cluster's data directory. The log records every change made to the database's data files. This log exists primarily for crash-safety purposes: if the system crashes, the database can be restored to consistency by "replaying" the log entries made since the last checkpoint. However, the existence of the log makes it possible to use a third strategy for backing up databases: we can combine a file-system-level backup with backup of the WAL files. If recovery is needed, we restore the file system backup and then replay from the backed-up WAL files to bring the system to a current state. This approach is more complex to administer than either of the previous approaches, but it has some significant benefits:

           Setting Up the WAL Archiving

In an abstract sense, a running PostgreSQL system produces an indefinitely long sequence of WAL records. The system physically divides this sequence into WAL segment files, which are normally 16MB a piece (although the segment size can be altered when building PostgreSQL). The segment files are given numeric names that reflect their position in the abstract WAL sequence. When not using WAL archiving, the system normally creates just a few segment files and then "recycles" them by renaming no-longer-needed segment files to higher segment numbers. It's assumed that segment files whose contents precede the checkpoint-before-last are no longer of interest and can be recycled.
 
When archiving WAL data, we need to capture the contents of each segment file once it is filled, and save that data somewhere before the segment file is recycled for reuse.
Depending on the application and the available hardware, there could be many different ways of "saving the data somewhere": we could copy the segment files to an NFS-mounted directory on another machine, write them onto a tape drive (ensuring that you have a way of identifying the original name of each file), or batch them together and burn them onto CDs, or something else entirely. To provide the database administrator with flexibility, PostgreSQL tries not to make any assumptions about how the archiving will be done. Instead, PostgreSQL lets the administrator specify a shell command to be executed to copy a completed segment file to wherever it needs to go. The command could be as simple as a cp, or it could invoke a complex shell script — it's all up to you.
 
To enable WAL archiving, set the wal_level configuration parameter to archive or higher, archive_mode to on, and specify the shell command to use in the archive_command configuration parameter.

In practice these settings will always be placed in the postgresql.conf e.g. (/etc/postgresql/12/main/postgresql.conf) file.

In archive_command, %p is replaced by the path name of the file to archive, while %f is replaced by only the file name. (The path name is relative to the current working directory, i.e., the cluster's data directory.)

Use %% if you need to embed an actual % character in the command.

The simplest useful command to enable PITR would, be something like:
 

# – Archiving config setction
 
archive_mode = on                    # enables archiving; off, on, or always
# (change requires restart)
 
archive_command = '/bin/xz -2 -z < %p > /var/lib/pgsql/9.5/archivedir/%f'               # command to use to archive a logfile segment
 
archive_timeout = 1h            # force a logfile segment switch after this
                                                   # number of seconds; 0 disables

How to automate open xen Hypervisor Virtual Machines backups shell script

Tuesday, June 22nd, 2021

openxen-backup-logo As a sysadmin that have my own Open Xen Debian Hypervisor running on a Lenovo ThinkServer few months ago due to a human error I managed to mess up one of my virtual machines and rebuild the Operating System from scratch and restore files service and MySQl data from backup that really pissed me of and this brought the need for having a decent Virtual Machine OpenXen backup solution I can implement on the Debian ( Buster) 10.10 running the free community Open Xen version 4.11.4+107-gef32c7afa2-1. The Hypervisor is a relative small one holding just 7 VM s:

HypervisorHost:~#  xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0 11102    24     r—–  214176.4
pcfrxenweb                                  11 12288     4     -b—-  247425.5
pcfrxen                                     12 16384    10     -b—-  1371621.4
windows7                                    20  4096     2     -b—-   97887.2
haproxy2                                    21  4096     2     -b—-   11806.9
jitsi-meet                                  22  2048     2     -b—-   12843.9
zabbix                                      23  2048     2     -b—-   20275.1
centos7                                     24  2040     2     -b—-   10898.2

HypervisorHost:~# xl list|grep -v 'Name ' |grep  -v 'Domain-0'  |wc -l
7


The backup strategy of the script is very simple to shutdown the running VM machine, make a copy with rsync to a backup location the image of each of the Virtual Machines in a bash shell loop for each virtual machine shown in output of xl command and backup to a preset local directory in my case this is /backups/ the backup of each virtual machine is produced within a separate backup directory with a respective timestamp. Backup VM .img files are produced in my case to mounted 2x external attached hard drives each of which is a 4 Terabyte Seagate Plus Backup (Storage). The original version of the script was made to be a slightly different by Zhiqiang Ma whose script I used for a template to come up with my xen VM backup solution. To prevent the Hypervisor's load the script is made to do it with a nice of (nice -n 10) this might be not required or you might want to modify it to better suit your needs. Below is the script itself you can fetch a copy of it /usr/sbin/xen_vm_backups.sh :

#!/bin/bash

# Author: Zhiqiang Ma (http://www.ericzma.com/)
# Modified to work with xl and OpenXen by Georgi Georgiev – https://pc-freak.net
# Original creation dateDec. 27, 2010
# Script takes all defined vms under xen_name_list and prepares backup of each
# after shutting down the machine prepares archive and copies archive in externally attached mounted /backup/disk1 HDD
# Latest update: 08.06.2021 G. Georgiev – hipo@pc-freak.net

mark_file=/backups/disk1/tmp/xen-bak-marker
log_file=/var/log/xen/backups/bak-$(date +%Y_%m_%d).log
err_log_file=/var/log/xen/backups/bak_err-$(date +%H_%M_%Y_%m_%d).log
xen_dir=/xen/domains
xen_vmconfig_dir=/etc/xen/
local_bak_dir=/backups/disk1/tmp
#bak_dir=xenbak@backup_host1:/lhome/xenbak
bak_dir=/backups/disk1/xen-backups/xen_images/$(date +%Y_%m_%d)/xen/domains
#xen_name_list="haproxy2 pcfrxenweb jitsi-meet zabbix windows7 centos7 pcfrxenweb pcfrxen"
xen_name_list="windows7 haproxy2 jitsi-meet zabbix centos7"

if [ ! -d /var/log/xen/backups ]; then
echo mkdir -p /var/log/xen/backups
 mkdir -p /var/log/xen/backups
fi

if [ ! -d $bak_dir ]; then
echo mkdir -p $bak_dir
 mkdir -p $bak_dir

fi


# check whether bak runned last week
if [ -e $mark_file ] ; then
        echo  rm -f $mark_file
 rm -f $mark_file
else
        echo  touch $mark_file
 touch $mark_file
  # exit 0
fi

# set std and stderr to log file
        echo mv $log_file $log_file.old
       mv $log_file $log_file.old
        echo mv $err_log_file $err_log_file.old
       mv $err_log_file $err_log_file.old
        echo "exec 2> $err_log_file"
       exec 2> $err_log_file
        echo "exec > $log_file"
       exec > $log_file


# check whether the VM is running
# We only backup running VMs

echo "*** Check alive VMs"

xen_name_list_tmp=""

for i in $xen_name_list
do
        echo "/usr/sbin/xl list > /tmp/tmp-xen-list"
        /usr/sbin/xl list > /tmp/tmp-xen-list
  grepinlist=`grep $i" " /tmp/tmp-xen-list`;
  if [[ “$grepinlist” == “” ]]
  then
    echo $i is not alive.
  else
    echo $i is alive.
    xen_name_list_tmp=$xen_name_list_tmp" "$i
  fi
done

xen_name_list=$xen_name_list_tmp

echo "Alive VM list:"

for i in $xen_name_list
do
   echo $i
done

echo "End alive VM list."

###############################
date
echo "*** Backup starts"

###############################
date
echo "*** Copy VMs to local disk"

for i in $xen_name_list
do
  date
  echo "Shutdown $i"
        echo  /usr/sbin/xl shutdown $i
        /usr/sbin/xl shutdown $i
        if [ $? != ‘0’ ]; then
                echo 'Not Xen Disk image destroying …';
                /usr/sbin/xl destroy $i
        fi
  sleep 30

  echo "Copy $i"
  echo "Copy to local_bak_dir: $local_bak_dir"
      echo /usr/bin/rsync -avhW –no-compress –progress $xen_dir/$i/{disk.img,swap.img} $local_bak_dir/$i/
     time /usr/bin/rsync -avhW –no-compress –progress $xen_dir/$i/{disk.img,swap.img} $local_bak_dir/$i/
      echo /usr/bin/rsync -avhW –no-compress –progress $xen_vmconfig_dir/$i.cfg $local_bak_dir/$i.cfg
     time /usr/bin/rsync -avhW –no-compress –progress $xen_vmconfig_dir/$i.cfg $local_bak_dir/$i.cfg
  date
  echo "Create $i"
  # with vmmem=1024"
  # /usr/sbin/xm create $xen_dir/vm.run vmid=$i vmmem=1024
          echo /usr/sbin/xl create $xen_vmconfig_dir/$i.cfg
          /usr/sbin/xl create $xen_vmconfig_dir/$i.cfg
## Uncomment if you need to copy with scp somewhere
###       echo scp $log_file $bak_dir/xen-bak-111.log
###      echo  /usr/bin/rsync -avhW –no-compress –progress $log_file $local_bak_dir/xen-bak-111.log
done

####################
date
echo "*** Compress local bak vmdisks"

for i in $xen_name_list
do
  date
  echo "Compress $i"
      echo tar -z -cfv $bak_dir/$i-$(date +%Y_%m_%d).tar.gz $local_bak_dir/$i-$(date +%Y_%m_%d) $local_bak_dir/$i.cfg
     time nice -n 10 tar -z -cvf $bak_dir/$i-$(date +%Y_%m_%d).tar.gz $local_bak_dir/$i/ $local_bak_dir/$i.cfg
    echo rm -vf $local_bak_dir/$i/ $local_bak_dir/$i.cfg
    rm -vrf $local_bak_dir/$i/{disk.img,swap.img}  $local_bak_dir/$i.cfg
done

####################
date
echo "*** Copy local bak vmdisks to remote machines"

copy_remote () {
for i in $xen_name_list
do
  date
  echo "Copy to remote: vm$i"
        echo  scp $local_bak_dir/vmdisk0-$i.tar.gz $bak_dir/vmdisk0-$i.tar.gz
done

#####################
date
echo "Backup finishes"
        echo scp $log_file $bak_dir/bak-111.log

}

date
echo "Backup finished"

 

Things to configure before start using using the script to prepare backups for you is the xen_name_list variable

#  directory skele where to store already prepared backups
bak_dir=/backups/disk1/xen-backups/xen_images/$(date +%Y_%m_%d)/xen/domains

# The configurations of the running Xen Virtual Machines
xen_vmconfig_dir=/etc/xen/
# a local directory that will be used for backup creation ( I prefer this directory to be on the backup storage location )
local_bak_dir=/backups/disk1/tmp
#bak_dir=xenbak@backup_host1:/lhome/xenbak
# the structure on the backup location where daily .img backups with be produced with rsync and tar archived with bzip2
bak_dir=/backups/disk1/xen-backups/xen_images/$(date +%Y_%m_%d)/xen/domains

# list here all the Virtual Machines you want the script to create backups of
xen_name_list="windows7 haproxy2 jitsi-meet zabbix centos7"

If you need the script to copy the backup of Virtual Machine images to external Backup server via Local Lan or to a remote Internet located encrypted connection with a passwordless ssh authentication (once you have prepared the Machines to automatically login without pass over ssh with specific user), you can uncomment the script commented section to adapt it to copy to remote host.

Once you have placed at place /usr/sbin/xen_vm_backups.sh use a cronjob to prepare backups on a regular basis, for example I use the following cron to produce a working copy of the Virtual Machine backups everyday.
 

# crontab -u root -l 

# create windows7 haproxy2 jitsi-meet centos7 zabbix VMs backup once a month
00 06 1,2,3,4,5,6,7,8,9,10,11,12 * * /usr/sbin/xen_vm_backups.sh 2>&1 >/dev/null


I do clean up virtual machines Images that are older than 95 days with another cron job

# crontab -u root -l

# Delete xen image files older than 95 days to clear up space from backup HDD
45 06 17 * * find /backups/disk1/xen-backups/xen_images* -type f -mtime +95 -exec rm {} \; 2>&1 >/dev/null

#### Delete xen config backups older than 1 year+3 days (368 days)
45 06 17 * * find /backups/disk1/xen-backups/xen_config* -type f -mtime +368 -exec rm {} \; 2>&1 >/dev/null

 

# Delete xen image files older than 95 days to clear up space from backup HDD
45 06 17 * * find /backups/disk1/xen-backups/xen_images* -type f -mtime +95 -exec rm {} \; 2>&1 >/dev/null

#### Delete xen config backups older than 1 year+3 days (368 days)
45 06 17 * * find /backups/disk1/xen-backups/xen_config* -type f -mtime +368 -exec rm {} \; 2>&1 >/dev/null