Back-in-time

**montana_suse_user** · 21-Nov-2020, 14:07

Several months ago, I installed the program back-in-time and configured it to backup, to my server, my home directory and an additional data drive. It seemed all was well as there are entries dated once a week shown on the server.

A week ago, I lost the root drive, which contained my home partition, and had to replace the drive. So, I lost / and /home. I did a clean install of Leap 15.2. During the install, I included back-in-time making it a new installation.

I am trying to restore the files from the server to the new drive but back-in-time tells me there are no snapshots. I have the sinking feeling that those snapshots were kept on what turned out to be the drive I lost.

There are many .gpg files on my server but I can't seem to get the new copy of back-in-time to recognize them.

Can anyone help me get the data restored to my drives?

**larryr** · 21-Nov-2020, 14:40

According to the Various Internet Sites - Back-in-time uses rsync.

All you lost is the GUI front end to find the files - they are in the backup directory there.

That means your files are there to copy - you just have to change directories and copy them back. Watch out for hard links - you need the real file to restore - the hard link points to the real file. I think you should be able to find all your data that way.

I would make a new user under /home like /home/olduser and copy the /home/username from the backup there.

When you have it done rename the existing user to newuser and rename olduser to the username and sync and init 6 to reboot.

If all goes right your old user and data will be there. If not - just reverse the renames and sync and reboot. This has worked for me to recover where someone deleted bin boot or usr but had a backup. (I had one user did a cd / tmp ; rm -rf * - he did not see the space before tmp and deleted his whole system).

I use rsync -av --delete to backup my large drive between machines.

I use tar to backup my main file system with the directories I need to backup also save the blkid so that you can create the same UUID's so the the boot will still work (no lost+found, dev, run, proc, sys or tmp - I create them on restore) and do a practice restore to a different drive once a quarter to make sure everything can be restored.

**karlmistelberger** · 21-Nov-2020, 14:57

Originally Posted by montana_suse_user

Several months ago, I installed the program back-in-time and configured it to backup, to my server, my home directory and an additional data drive. It seemed all was well as there are entries dated once a week shown on the server.

A week ago, I lost the root drive, which contained my home partition, and had to replace the drive. So, I lost / and /home. I did a clean install of Leap 15.2. During the install, I included back-in-time making it a new installation.

I am trying to restore the files from the server to the new drive but back-in-time tells me there are no snapshots. I have the sinking feeling that those snapshots were kept on what turned out to be the drive I lost.

There are many .gpg files on my server but I can't seem to get the new copy of back-in-time to recognize them.

Can anyone help me get the data restored to my drives?

Mount your backup as follows and show what you have:

Code:

erlangen:~ # btrfs filesystem show  
Label: 'TW-20200515'  uuid: e7ad401f-4f60-42ff-a07e-f54372bc1dbc 
        Total devices 1 FS bytes used 23.21GiB 
        devid    1 size 51.69GiB used 30.05GiB path /dev/nvme0n1p2 

Label: 'Tumbleweed'  uuid: 204f7d0f-979a-41e1-a483-a597d0357e0b 
        Total devices 1 FS bytes used 25.21GiB 
        devid    2 size 60.00GiB used 29.03GiB path /dev/sdc5 

Label: 'Leap-15.2'  uuid: 69774d55-8da2-4599-9c27-766b1012771d 
        Total devices 1 FS bytes used 15.99GiB 
        devid    1 size 28.13GiB used 17.30GiB path /dev/sdc8 
erlangen:~ # mount /dev/sdc5 -o subvolid=5 /mnt/ 
erlangen:~ # btrfs subvolume list /mnt/ 
ID 256 gen 485846 top level 5 path @ 
ID 258 gen 487945 top level 256 path @/var 
ID 259 gen 486554 top level 256 path @/usr/local 
ID 260 gen 485206 top level 256 path @/tmp 
ID 261 gen 487380 top level 256 path @/srv 
ID 262 gen 487933 top level 256 path @/root 
ID 263 gen 487928 top level 256 path @/opt 
ID 264 gen 486479 top level 256 path @/boot/grub2/x86_64-efi 
ID 265 gen 484942 top level 256 path @/boot/grub2/i386-pc 
ID 266 gen 487931 top level 256 path @/.snapshots 
ID 2738 gen 485215 top level 266 path @/.snapshots/1902/snapshot 
ID 2739 gen 487945 top level 266 path @/.snapshots/1903/snapshot 
ID 2740 gen 485215 top level 266 path @/.snapshots/1904/snapshot 
ID 2741 gen 485215 top level 266 path @/.snapshots/1905/snapshot 
ID 2782 gen 485255 top level 266 path @/.snapshots/1908/snapshot 
ID 2784 gen 485458 top level 266 path @/.snapshots/1909/snapshot 
ID 2785 gen 485466 top level 266 path @/.snapshots/1910/snapshot 
ID 2786 gen 485468 top level 266 path @/.snapshots/1911/snapshot 
ID 2791 gen 485515 top level 266 path @/.snapshots/1916/snapshot 
ID 2792 gen 485517 top level 266 path @/.snapshots/1917/snapshot 
ID 2793 gen 485518 top level 266 path @/.snapshots/1918/snapshot 
ID 2794 gen 485519 top level 266 path @/.snapshots/1919/snapshot 
ID 2797 gen 485764 top level 266 path @/.snapshots/1922/snapshot 
ID 2798 gen 485766 top level 266 path @/.snapshots/1923/snapshot 
ID 2799 gen 485871 top level 266 path @/.snapshots/1924/snapshot 
ID 2801 gen 486160 top level 266 path @/.snapshots/1925/snapshot 
ID 2802 gen 486162 top level 266 path @/.snapshots/1926/snapshot 
ID 2803 gen 486164 top level 266 path @/.snapshots/1927/snapshot 
ID 2804 gen 486355 top level 266 path @/.snapshots/1928/snapshot 
ID 2805 gen 486359 top level 266 path @/.snapshots/1929/snapshot 
ID 2806 gen 486363 top level 266 path @/.snapshots/1930/snapshot 
ID 2807 gen 486365 top level 266 path @/.snapshots/1931/snapshot 
ID 2808 gen 486476 top level 266 path @/.snapshots/1932/snapshot 
ID 2809 gen 486477 top level 266 path @/.snapshots/1933/snapshot 
ID 2810 gen 486478 top level 266 path @/.snapshots/1934/snapshot 
ID 2811 gen 486481 top level 266 path @/.snapshots/1935/snapshot 
ID 2812 gen 486485 top level 266 path @/.snapshots/1936/snapshot 
ID 2813 gen 486488 top level 266 path @/.snapshots/1937/snapshot 
ID 2814 gen 486491 top level 266 path @/.snapshots/1938/snapshot 
ID 2815 gen 487728 top level 266 path @/.snapshots/1939/snapshot 
ID 2817 gen 487912 top level 266 path @/.snapshots/1940/snapshot 
ID 2818 gen 487924 top level 266 path @/.snapshots/1941/snapshot 
ID 2819 gen 487926 top level 266 path @/.snapshots/1942/snapshot 
ID 2820 gen 487929 top level 266 path @/.snapshots/1943/snapshot 
ID 2821 gen 487930 top level 266 path @/.snapshots/1944/snapshot 
erlangen:~ #

You may access files by using the full pathname, e.g.:

Code:

erlangen:~ # ll /mnt/@/.snapshots/1902/snapshot/etc/vconsole.conf 
-rw-r--r-- 1 root root 47 May 26 08:54 /mnt/@/.snapshots/1902/snapshot/etc/vconsole.conf 
erlangen:~ # cat /mnt/@/.snapshots/1902/snapshot/etc/vconsole.conf 
KEYMAP=de-latin1-nodeadkeys 
FONT=eurlatgr.psfu 
erlangen:~ #

**deano_ferrari** · 21-Nov-2020, 15:04

Originally Posted by karlmistelberger

Mount your backup as follows and show what you have:

A lost cause if the backups are lost though....the OP mentioned....

I am trying to restore the files from the server to the new drive but back-in-time tells me there are no snapshots. I have the sinking feeling that those snapshots were kept on what turned out to be the drive I lost.

Only the OP can verify that though.

**montana_suse_user** · 21-Nov-2020, 16:07

I seem to be on the way!
On my server are 4432 files named as duplicity-full.20200903T091524Z.volXXXX.difftar.gpg
I copied all these files to ~/Spare-1 to fuss with.
The .gpg extension led me to believe these files are encrypted. So I did:

Code:

bart@UNIVAC:~/Spare-1> gpg duplicity-full.20200903T091524Z.vol10.difftar.gpg

and when prompted, gave a password. I ended up with a file named

Code:

duplicity-full.20200903T091524Z.vol10.difftar

The icon in Dolphin showed a brown box so I clicked on it and sure enough, it showed some files with sizes that seem to match what I'd expect! Hurray!

Now! Is there a CLI command I can issue to make the gpg command go through the entire set of .gpg files in this directory and place it output files into another directory? (Spare-1 doesn't have the room)

Bart

**larryr** · 21-Nov-2020, 17:18

Simple bash script like this:

Code:

bart@UNIVAC:~/Spare-1> for x in *.gpg ; do ; gpg $x ; done

**montana_suse_user** · 21-Nov-2020, 17:28

Code:

bart@UNIVAC:~/Spare-1> for x in *.gpg ; do ; gpg $x ; done
bash: syntax error near unexpected token `;'

**tsu2** · 21-Nov-2020, 18:21

I don't use Back in Time, but note the official documentation

https://backintime.readthedocs.io/en/latest/

Suggests that all backups are in plain text and not encrypted.
Also no word that compressions is supported, and I assume "difftar" likely is a hint that tar is being used to create a differential backup or contains changes from some other reference.

It also says that permissions are stored separately from the file archives, and the only way you'll restore both files and permissions is to use the Back in Time app, so you shouldn't just copy files back to their original locations.

Could these gpg files be something else that was run on your machine and not Back in Time backups?

TSU

**larryr** · 21-Nov-2020, 18:49

Originally Posted by montana_suse_user

Code:

bart@UNIVAC:~/Spare-1> for x in *.gpg ; do  gpg $x ; done

no ";" after do - my error - I rarely do one liners. I fixed it above.

**montana_suse_user** · 22-Nov-2020, 00:36

Originally Posted by tsu2

I don't use Back in Time, but note the official documentation

https://backintime.readthedocs.io/en/latest/

Suggests that all backups are in plain text and not encrypted.

In the directory where I had the backup sent, there are a huge number of files with names like

Code:

duplicity-inc.20201015T091513Z.to.20201022T091515Z.vol18.difftar.gpg

, If I open one of them with Kate, they're unreadable. If I use gpg and the filename, it asks for a password. I give it my root password and it creates a file of the same name only without the gpg extension. If I open that file, it uses arc and shows a list of the files and directories. Anything bigger than about 1k is shown as small blocks numbered sequentially starting at 1. Some of the bigger source files are shown in several different .gpg files, so they need to be put back together.

Also no word that compressions is supported, and I assume "difftar" likely is a hint that tar is being used to create a differential backup or contains changes from some other reference.

Looking at the size of the complete backup and the space taken on my drives, I would think that some sort of compression is used.

It also says that permissions are stored separately from the file archives, and the only way you'll restore both files and permissions is to use the Back in Time app, so you shouldn't just copy files back to their original locations.

I understood that only referred to a backup made via SSH. Of course I could be wrong.

Could these gpg files be something else that was run on your machine and not Back in Time backups?

TSU

No. I created a folder on my server for the exclusive use of back-in-time.

After using gpg to decrypt these gpg files, any file that is small enough to have fit into one of their blocks, such as a small picture or the like, seems to be usable. I did not check the permissions but using the GUI and clicking on the file, used the correct application to open and display the file.

The entire set of files created by back-in-time and placed on the server seem to be intact on the server. I haven't messed with them. I made a copy on one of my spare drives to play with.

The new back-in-time program seems to be intact and operating as designed. But, it seems that it won't go and look for a snapshot made by a previous incarnation of the program. I find that disturbing as the primary reason for it is to backup data and be able to restore it. If one loses their root drive, the OS and all the programs need to be reinstalled from the repositories. The information necessary for restoring backup copies should reside with the data, no?

Bottom line, it seems I am going to need back-in-time to restore my data. I'm going to have to find a way to get it to recognize the backup set it made.

Bart