Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Support
  3. Restoring file timestamps from backup / migration

Restoring file timestamps from backup / migration

Scheduled Pinned Locked Moved Solved Support
backups
7 Posts 2 Posters 1.1k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • robiR Offline
      robiR Offline
      robi
      wrote on last edited by girish
      #1

      This is a fairly serious issue, since file content is time stamped and sorted at the filesystem level.

      Restoring a backup doesn't seem to restore the original timestamps from the time of backup. (tgz)

      Performing a storage migration also does not preserve the timestamps for older content. (cp)

      What parameters are being used for cp migration & tgz restore from backup ?

      How do we make this work?

      Conscious tech

      1 Reply Last reply
      0
      • girishG Offline
        girishG Offline
        girish
        Staff
        wrote on last edited by
        #2

        Generally, web apps don't care about filesystem timestamps. Is this because of surfer showing the filesystem timestamps?

        robiR 1 Reply Last reply
        1
        • girishG girish

          Generally, web apps don't care about filesystem timestamps. Is this because of surfer showing the filesystem timestamps?

          robiR Offline
          robiR Offline
          robi
          wrote on last edited by
          #3

          @girish Yes, it's also a file server for us.

          Conscious tech

          girishG 1 Reply Last reply
          0
          • robiR robi

            @girish Yes, it's also a file server for us.

            girishG Offline
            girishG Offline
            girish
            Staff
            wrote on last edited by
            #4

            @robi For tgz restore, timestamps are restored for me. Can you check if the timestamps are stored correctly in the backup using tar -ztvf app_xx.tar.gz ? For example, in my case, I see:

            -rw-r--r-- 0/0               0 2009-11-17 15:33 ./data/public/try
            

            Then, after restore, I can confirm that the timestamp is the same. Same for the data migration, after the migrate, the timestamp is preserved:

            root@vultr:/mnt/surferdata/public# ls -lh
            total 4.0K
            -rw-r--r-- 1 yellowtent yellowtent    0 Nov 17  2009 try
            
            
            1 Reply Last reply
            0
            • girishG Offline
              girishG Offline
              girish
              Staff
              wrote on last edited by
              #5

              It is possible you are using rsync and not tgz? If so, yes, timestamps are not restored for rsync case. I guess we need a mechanism to save all the timestamps in some meta file and restore them back.

              1 Reply Last reply
              0
              • robiR Offline
                robiR Offline
                robi
                wrote on last edited by
                #6

                It appears the backup was changed to rsync, and the FTP client config wasn't preserving timestamps when missing content was reuploaded.

                We're ok for now, in this use case.

                rsync could be 'fixed' by using .tar before the rsync.
                Could be made more efficient too if a fixed chunk size or stream was used, so all the small file operations don't need to be done.

                Conscious tech

                girishG 1 Reply Last reply
                0
                • robiR robi

                  It appears the backup was changed to rsync, and the FTP client config wasn't preserving timestamps when missing content was reuploaded.

                  We're ok for now, in this use case.

                  rsync could be 'fixed' by using .tar before the rsync.
                  Could be made more efficient too if a fixed chunk size or stream was used, so all the small file operations don't need to be done.

                  girishG Offline
                  girishG Offline
                  girish
                  Staff
                  wrote on last edited by
                  #7

                  @robi there is a already bunch of "workarounds" for rsync. Empty directories, executable bit of files cannot be stored in most object storage. So, there is fsmetadata.json file that stores this information outside of the files. When restoring, we use that file to restore back the state. I guess we can extend that file to also save and restore timestamps.

                  If anyone wants this leave a note and I can look into it in the future.

                  1 Reply Last reply
                  2
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Bookmarks
                    • Search