Stuck in emergency mode, cannot restore snapshot with Timeshift

sudo timeshift --list
[sudo] Passwort für sgs:    
Mounted '/dev/nvme0n1p2' at '/run/timeshift/backup'
Device : /dev/nvme0n1p2
UUID   : 35075ddb-bcf7-47aa-a43a-e759a082af57
Path   : /run/timeshift/backup
Mode   : BTRFS
Status : OK
5 snapshots, 929.9 GB free

Num     Name                 Tags  Description                                    
------------------------------------------------------------------------------
0    >  2021-08-20_20-37-03  O     {timeshift-autosnap} {created before upgrade}  
1    >  2021-08-21_01-31-13  O     {timeshift-autosnap} {created before upgrade}  
2    >  2021-08-21_14-06-42  O     {timeshift-autosnap} {created before upgrade}  
3    >  2021-08-21_16-19-57  O     {timeshift-autosnap} {created before upgrade}  
4    >  2021-08-21_17-31-47  O     {timeshift-autosnap} {created before upgrade}  

If empty you have no luck.

 /dev/nvme0n1p1 is mounted at: /run/timeshift/backup, options: rw,relatime,ssd,space_cache,subvolid=5,subvol=/

E: JSON data must be UTF-8 encoded

(process:7128): Json-CRITICAL **: 20:09:07.058: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed
E: JSON data must be UTF-8 encoded

(process:7128): Json-CRITICAL **: 20:09:07.058: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed
E: JSON data must be UTF-8 encoded

(process:7128): Json-CRITICAL **: 20:09:07.058: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed
E: JSON data must be UTF-8 encoded

(process:7128): Json-CRITICAL **: 20:09:07.059: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed
E: JSON data must be UTF-8 encoded

(process:7128): Json-CRITICAL **: 20:09:07.059: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed
E: JSON data must be UTF-8 encoded

(process:7128): Json-CRITICAL **: 20:09:07.059: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed
E: JSON data must be UTF-8 encoded

(process:7128): Json-CRITICAL **: 20:09:07.060: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed
E: JSON data must be UTF-8 encoded

(process:7128): Json-CRITICAL **: 20:09:07.060: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed
E: JSON data must be UTF-8 encoded

(process:7128): Json-CRITICAL **: 20:09:07.060: json_node_get_object: assertion 'JSON_NODE_IS_VALID (node)' failed
E: /run/timeshift/backup/timeshift-btrfs/snapshots/2021-08-18_01-20-31/info.json:1:11: Parse error: unexpected character `:', expected end of file

(process:7128): Json-CRITICAL **: 20:09:07.061: json_node_get_object: assertion 'JSON_NODE_TYPE (node) == JSON_NODE_OBJECT' failed
Device : /dev/nvme0n1p1
UUID   : cbefe62a-05be-4e49-9034-013f48f815a6
Path   : /run/timeshift/backup
Mode   : BTRFS
Status : No snapshots on this device
First snapshot requires: 0 B

No snapshots found

Okay, as I explained above I can see my entire drive in Dolphin, including my snapshots with my Home folder. The reason Timeshift is not detecting my backups is because the info.json file is corrupted. Here is an example of what it would look like:

  "created" : "1544955020",
  "sys-uuid" : "46b1f5a5-00b4-4ce1-a181-dc815668c599",
  "sys-distro" : "arch",
  "app-version" : "18.9.1",
  "file_count" : "0",
  "tags" : "ondemand",
  "comments" : "",
  "live" : "false",
  "type" : "btrfs",
  "subvolumes" : {
    "@home" : [
      "@home",
      "839",
      "291924873216",
      "5621964800",
      "46b1f5a5-00b4-4ce1-a181-dc815668c599"
    ],
    "@" : [
      "@",
      "838",
      "18277564416",
      "239136768",
      "46b1f5a5-00b4-4ce1-a181-dc815668c599"
    ]
  }

All I need to know right now is what do all of these entries mean so that I can fill it out with the correct information and Timeshift can detect my snapshots.

My next/last desperate try...
Chroot and try
sudo timeshift --create --comments "A new backup" --tags O
Just to see if you can manage to create a new info.json to replace the others...

 Using system disk as snapshot device for creating snapshots in BTRFS mode
Option --snapshot-device should not be specified for creating snapshots in BTRFS mode

** (process:245): CRITICAL **: 16:42:23.905: tee_jee_file_system_path_combine: assertion 'path1 != NULL' failed

** (process:245): CRITICAL **: 16:42:23.905: tee_jee_file_system_dir_exists: assertion 'dir_path != NULL' failed

** (process:245): CRITICAL **: 16:42:23.907: tee_jee_file_system_path_combine: assertion 'path1 != NULL' failed

** (process:245): CRITICAL **: 16:42:23.907: tee_jee_file_system_dir_exists: assertion 'dir_path != NULL' failed
E: Selected snapshot device is not a system disk
E: Select BTRFS system disk with root subvolume (@)

Hi there, any good progress here?
I just realized I didn’t send you an example of info.json from my timeshift, as I intended to do, for you to try and understand how to adjust it and use it.
This is the /run/timeshift/backup/timeshift-btrfs/snapshots/2021-08-24_19-38-55/info.json file created earlier when I updated my system:

{
  "created" : "1629826735",
  "sys-uuid" : "3c9fe0e6-78b5-41ec-8f40-7afc2f674b86",
  "sys-distro" : "Garuda Soaring (Bateleur)",
  "app-version" : "20.11.1",
  "file_count" : "0",
  "tags" : "ondemand",
  "comments" : "{timeshift-autosnap} {created before upgrade}",
  "live" : "false",
  "type" : "btrfs",
  "subvolumes" : {
    "@" : [
      "@",
      "523",
      "8425115648",
      "167624704",
      "3c9fe0e6-78b5-41ec-8f40-7afc2f674b86"
    ]
  }
}

I think what is really important is the sys-uuid (of your disk) at the top and bottom according to your /etc/fstab. Below my example:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=C86F-B725                            /boot/efi      vfat    umask=0077 0 2
UUID=3c9fe0e6-78b5-41ec-8f40-7afc2f674b86 /              btrfs   subvol=@,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd 0 1
UUID=3c9fe0e6-78b5-41ec-8f40-7afc2f674b86 /home          btrfs   subvol=@home,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd 0 2
UUID=3c9fe0e6-78b5-41ec-8f40-7afc2f674b86 /root          btrfs   subvol=@root,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd 0 2
UUID=3c9fe0e6-78b5-41ec-8f40-7afc2f674b86 /srv           btrfs   subvol=@srv,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd 0 2
UUID=3c9fe0e6-78b5-41ec-8f40-7afc2f674b86 /var/cache     btrfs   subvol=@cache,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd 0 2
UUID=3c9fe0e6-78b5-41ec-8f40-7afc2f674b86 /var/log       btrfs   subvol=@log,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd 0 2
UUID=3c9fe0e6-78b5-41ec-8f40-7afc2f674b86 /var/tmp       btrfs   subvol=@tmp,defaults,noatime,space_cache,autodefrag,compress=zstd,ssd 0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

And the 523 (in my example), according to your

sudo btrfs subvolume list /
ID 257 gen 24462 top level 5 path @home
ID 258 gen 24444 top level 5 path @root
ID 259 gen 21956 top level 5 path @srv
ID 260 gen 24396 top level 5 path @cache
ID 261 gen 24463 top level 5 path @log
ID 262 gen 24430 top level 5 path @tmp
ID 439 gen 24462 top level 5 path @
ID 520 gen 24364 top level 5 path timeshift-btrfs/snapshots/2021-08-20_22-27-15/@
ID 521 gen 24420 top level 5 path timeshift-btrfs/snapshots/2021-08-20_22-29-30/@
ID 523 gen 24420 top level 5 path timeshift-btrfs/snapshots/2021-08-24_19-38-55/@

Pay also special attention to the /etc/fstab: in a recent thread the (different) issue was linked to a wrong / mount point there.
You also may want to delete some older timeshift folders before everything.

1 Like

Not to be cruel, but any system that backs up to the same drive as the source is not a bone fide backup system. Timeshift is more a system restore type of utility, and is not a replacement for a full backup regime.

That is precisely why we include a disclaimer about Timeshift on our main page. Timeshift is a handy system restore feature, but it is not guaranteed to be able to restore a severely corrupted/unbootable system. For that peace of mind you need to implement your own dedicated backup regime to an external drive.

3 Likes

sorry i am late to this topic, but am I missing something or can you test if the files in the snapshots are OK? any one of these:

ID 520 gen 24364 top level 5 path timeshift-btrfs/snapshots/2021-08-20_22-27-15/@
ID 521 gen 24420 top level 5 path timeshift-btrfs/snapshots/2021-08-20_22-29-30/@
ID 523 gen 24420 top level 5 path timeshift-btrfs/snapshots/2021-08-24_19-38-55/@

? if they are, a simple

mv @ to _backup_@ && mv timeshift-btrfs/snapshots/2021-08-24_19-38-55/@ @

should fix it, right ?

since @ and the timeshift btrfs seem to be all in the same root, the mv command should be instant. If not I would recommend cp with --reflink=always ( also instantaneous , even on different path volumes )

But the real good advice, is backup all the important files in those snapshot folders ASAP.

That was only the list of my snapshots (which should be ok, although I didn't have to restore in the recent months luckily :smiley:) used to explain how the info.json file is structured, since the OP could be affected by an issue with info.json corrupted, which could be solved by simply copying a new good file in an existing snapshot folder.

damn ... what a blunder !! sorry , I completely misunderstood things ( I guess I really was missing something )

Sorry, to much fast reading and scrolling down :frowning:

1 Like

So after days of trying stuff out, I tried this method to get the snapshots to show up, and they did except that the only problem was that they were all created after my pc got corrupted, don't really know why. I ended up simply having to start from scratch. But it did solve my biggest issue of trying to get the snapshots to show up, so I will be marking @filo's answer w/ their example timeshift info.json as the solution for this thread.

1 Like

Maybe this is due to my

Which was my creation date/time

I don’t know if this was the date shown in your system.
Sorry you had to reinstall.
At least it has been a way to learn something more on timeshift…

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.