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.3k 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