તમારા એપ ડેટાબેઝનો બેકઅપ કેવી રીતે લેવો (અને ખરેખર રિસ્ટોર કેવી રીતે કરવો)

તમારી એપનો ડેટાબેઝ બેકઅપ લેવા માટે તેને શેડ્યૂલ પર ફાઇલમાં એક્સપોર્ટ કરો (Postgres માટે માનક ટૂલ pg_dump છે), નકલો ડેટાબેઝથી અલગ જગ્યાએ રાખો, અને નિયમિત રીતે ખાલી ડેટાબેઝમાં એક નકલ રિસ્ટોર કરીને ચકાસો કે તે કામ કરે છે. કોઈ જોખમી ફેરફાર પહેલાં વધારાનો બેકઅપ લો. તમારો કોડ બેકઅપ, પછી તે GitHub રિપોઝિટરી હોય કે એક્સપોર્ટ, તમારો ડેટા સમાવતો નથી.

આ માર્ગદર્શન એવા લોકો માટે છે જે નાની એપ ચલાવે છે અને તેને ગુમાવવાની ચિંતા બંધ કરવા માંગે છે. ઉદાહરણોમાં Postgres વપરાયું છે, કારણ કે મોટાભાગની AI-બનાવેલી એપ્સ તેનો ઉપયોગ કરે છે, પરંતુ આ સિદ્ધાંતો કોઈપણ ડેટાબેઝને લાગુ પડે છે.

બેકઅપમાં શું આવરી લેવું પડે

એપ માત્ર તેના ડેટાબેઝ કરતાં વધુ છે. દરેક બેકઅપ કયો ભાગ સુરક્ષિત કરે છે તે જાણો.

જે ડેટા ફરીથી બનાવી શકાતો નથી તે જ સૌથી મહત્વનો છે. કોડ ફરીથી લખી શકાય છે અને સેટિંગ્સ ફરીથી દાખલ કરી શકાય છે; તમારા ગ્રાહકોના ઓર્ડર નહીં.

પગલું 1: નક્કી કરો કે તમે કેટલો ડેટા ગુમાવી શકો

બે પ્રશ્નો તમારી બેકઅપ યોજના નક્કી કરે છે:

• તાજેતરનો કેટલો ડેટા ગુમાવવો પોસાય? જો તમે દિવસમાં એક વાર બેકઅપ લો અને સાંજે ડેટાબેઝ ફેલ થાય, તો તે દિવસના ફેરફાર ગુમાવશો. નાની હોબી એપ માટે તે ઠીક છે. ઓર્ડર લેતી એપ માટે કદાચ નહીં.
• રિસ્ટોર દરમિયાન એપ કેટલો સમય બંધ રહી શકે? નાનો ડેટાબેઝ મિનિટોમાં રિસ્ટોર થાય છે. મોટો ડેટાબેઝ ઘણો વધુ સમય લઈ શકે છે, અને જરૂર પડે તે પહેલાં તમારે તે જાણવું જોઈએ.

મોટાભાગની નાની એપ્સ માટે દરરોજ ઓટોમેટિક બેકઅપ, ઉપરાંત જોખમી ફેરફારો પહેલાં મેન્યુઅલ બેકઅપ, એક સમજદાર શરૂઆત છે. પૈસા અથવા આરોગ્ય ડેટા સામેલ હોય તેવી એપ્સને વધુ વારંવાર બેકઅપ, અથવા પોઇન્ટ-ઇન-ટાઇમ રિકવરી (કોઈ પણ ક્ષણ પર રિસ્ટોર કરવાની ક્ષમતા, માત્ર છેલ્લા બેકઅપ સુધી નહીં) ધરાવતો મેનેજ્ડ ડેટાબેઝ જોઈએ.

પગલું 2: તમારો હોસ્ટ પહેલેથી શું કરે છે તે તપાસો

ઘણા મેનેજ્ડ ડેટાબેઝ પ્રદાતાઓ ઓટોમેટિક બેકઅપ લે છે. જાણો:

• શું તમારા પ્લાન માટે બેકઅપ ચાલુ છે, અને તે કેટલી વારે ચાલે છે?
• તેઓ કેટલો સમય રાખે છે?
• શું તમે કોઈ ચોક્કસ ક્ષણ પર રિસ્ટોર કરી શકો છો, કે માત્ર દૈનિક સ્નેપશોટ પર?
• શું તમે બેકઅપ ડાઉનલોડ કરી શકો છો, કે માત્ર તેમની સિસ્ટમમાં જ રિસ્ટોર કરી શકો છો?

પ્રદાતાના બેકઅપ ઉપયોગી છે, પરંતુ તેઓ તમારા ડેટાબેઝ સાથે એક જ સિંગલ પોઇન્ટ ઓફ ફેલ્યોર શેર કરે છે: ખાતું. જો ખાતું બંધ થાય, સસ્પેન્ડ થાય અથવા પ્રોજેક્ટ ડિલીટ થાય, તો બેકઅપ પણ સાથે જઈ શકે છે. તેથી તમારી પોતાની નકલ પણ જરૂરી છે.

પગલું 3: pg_dump વડે ડમ્પ બનાવો

pg_dump Postgres ડેટાબેઝને ફાઇલમાં એક્સપોર્ટ કરે છે. તે સુસંગત સ્નેપશોટ વાંચે છે, એટલે તે કામ કરે ત્યારે પણ એપ ચાલુ રહી શકે છે.

એક સામાન્ય કમાન્ડ, જે તમારી એપ પહેલેથી પર્યાવરણ ચલમાં ધરાવતી કનેક્શન સ્ટ્રિંગનો ઉપયોગ કરે છે:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

વિકલ્પો શું કરે છે:

• --format=custom એક કમ્પ્રેસ્ડ ફાઇલ લખે છે જે pg_restore વાંચી શકે છે, અને પછીથી એક ટેબલ અલગ રિસ્ટોર કરવા દે છે. જો તમને વાંચી શકાય તેવી .sql ફાઇલ જોઈતી હોય તો --format=plain વાપરો.
• --no-owner માલિકી કમાન્ડ છોડી દે છે, જેથી જુદા ડેટાબેઝમાં રિસ્ટોર કરવું સરળ બને.
• ફાઇલના નામમાંની તારીખ બેકઅપને અલગ રાખે છે.

pg_dump નું વર્ઝન તમારા ડેટાબેઝના Postgres વર્ઝન જેટલું અથવા તેનાથી નવું હોવું જોઈએ. જૂનું pg_dump ચાલવાનો ઇનકાર કરી શકે છે.

જો તમે AI સાથે બનાવો છો અને કમાન્ડ લાઇનને સ્પર્શવા માંગતા નથી, તો તમે પૂછી શકો છો:

pg_dump વડે કસ્ટમ ફોર્મેટમાં એપના ડેટાબેઝનો બેકઅપ બનાવો, ફાઇલના નામમાં આજની તારીખ સાથે. કનેક્શન સ્ટ્રિંગ કે કોઈ સિક્રેટ છાપશો નહીં. પૂરું થાય ત્યારે મને ફાઇલનું નામ અને તેનું કદ કહો.

પગલું 4: તેને ઓટોમેટ કરો

મેન્યુઅલ બેકઅપ ભુલાઈ જાય છે. તમારા સેટઅપ જે સપોર્ટ કરે તે વડે તેને ઓટોમેટ કરો:

• તમારા ડેટાબેઝ પ્રદાતાના શેડ્યૂલ્ડ બેકઅપ, જો તે ઓફર કરે તો.
• સર્વર પર કે CI સેવા પર શેડ્યૂલ્ડ જોબ જે pg_dump ચલાવે અને ફાઇલને સ્ટોરેજમાં અપલોડ કરે.
• હોસ્ટેડ બેકઅપ સેવા જે તમારા ડેટાબેઝ સાથે જોડાય.

જે પણ પસંદ કરો, તે નિષ્ફળ થાય ત્યારે તમને જાણ કરે તેની ખાતરી કરો. બેકઅપ જોબ જે ત્રણ મહિનાથી ચુપચાપ નિષ્ફળ થઈ રહી છે તે ક્લાસિક ભયાનક વાર્તા છે.

પગલું 5: નકલો બીજે ક્યાંક રાખો

નિયમને ઘણીવાર 3-2-1 કહેવામાં આવે છે: તમારા ડેટાની ત્રણ નકલો, બે જુદા પ્રકારના સ્ટોરેજ પર, અને એક ઓફ-સાઇટ. નાની એપ માટે વ્યવહારુ રૂપ આ છે:

• લાઇવ ડેટાબેઝ
• પ્રદાતાના પોતાના ઓટોમેટિક બેકઅપ
• તમારા પોતાના ડમ્પ, જુદા ખાતામાં ઓબ્જેક્ટ સ્ટોરેજ બકેટ જેવા અલગ સ્ટોરેજમાં

ઉપરાંત:

• ઍક્સેસ મર્યાદિત કરો. બેકઅપમાં દરેક યુઝરનો ડેટા હોય છે. તેને લાઇવ ડેટાબેઝ જેટલો જ ગણો.
• રીટેન્શન પોલિસી રાખો. ઉદાહરણ તરીકે, બે અઠવાડિયા સુધી દૈનિક બેકઅપ અને એક વર્ષ સુધી માસિક. જૂના બેકઅપ ઇરાદાપૂર્વક ડિલીટ કરો, અને યાદ રાખો કે ગોપનીયતા કાયદા કદાચ તમને વિનંતી પર વ્યક્તિગત ડેટા ડિલીટ કરવાનું કહે.
• ક્યારેય બેકઅપ Git માં કમિટ ન કરો. રિપોઝિટરીમાંનો ડમ્પ ડેટા લીક થવાની રાહ જોતો ખતરો છે.

પગલું 6: રિસ્ટોર ચકાસો

બેકઅપ તેટલો જ સારો છે જેટલો તમારો છેલ્લો સફળ રિસ્ટોર. ઓછામાં ઓછા દર થોડા મહિને, અને બેકઅપ પ્રક્રિયામાં કોઈ પણ ફેરફાર પછી:

1. નવો, ખાલી ડેટાબેઝ બનાવો. પરીક્ષણ માટે ક્યારેય લાઇવ પર રિસ્ટોર ન કરો.
2. સૌથી તાજો બેકઅપ તેમાં રિસ્ટોર કરો:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

સાદી .sql ફાઇલ માટે તેના બદલે psql "$TEST_DATABASE_URL" -f backup.sql વાપરો.

1. ચકાસો કે દરેક ટેબલ છે, લાઇવ ડેટાબેઝ સાથે પંક્તિઓની સંખ્યા સરખાવો, અને થોડા તાજા રેકોર્ડ જુઓ.
2. જો શક્ય હોય તો એપની એક નકલ તેની તરફ ઇંગિત કરો અને લોગ ઇન કરો.
3. રિસ્ટોરમાં કેટલો સમય લાગ્યો તે લખી રાખો. તે તમારો વાસ્તવિક રિકવરી સમય છે.

પગલું 7: જોખમી ફેરફારો પહેલાં બેકઅપ લો

નીચેના કામ પહેલાં તાજો બેકઅપ લો:

• કોલમ ડ્રોપ કે રિનેમ કરતું ડેટાબેઝ માઇગ્રેશન ચલાવવું
• મોટા પ્રમાણમાં ડેટા ઇમ્પોર્ટ કરવો
• AI એજન્ટને ડેટા મોડેલમાં મોટા ફેરફાર કરવા દેવા
• જૂના રેકોર્ડ ડિલીટ કરવા

AI-બનાવેલી એપમાં, એજન્ટ કોઈ સુવિધાના ભાગ રૂપે ટેબલનું માળખું બદલી શકે છે. ચેકપોઇન્ટ અને વર્ઝન કંટ્રોલ તમારો કોડ રોલબેક કરે છે, પરંતુ તેઓ ડિલીટ થયેલી પંક્તિઓ પાછી લાવતા નથી. મોટા ફેરફાર પહેલાં ત્રીસ સેકન્ડનો બેકઅપ સસ્તો વીમો છે.

સામાન્ય ભૂલો

• Git અથવા કોડ એક્સપોર્ટને બેકઅપ માની લેવો. તેમાં કોડ છે, ડેટા નહીં.
• રિસ્ટોર ક્યારેય ચકાસવો નહીં. ઘણા બેકઅપ જરૂર પડે ત્યારે જ ખાલી, અધૂરા કે વાંચી ન શકાય તેવા નીકળે છે.
• ડેટાબેઝ જેવા જ ખાતામાં બેકઅપ રાખવા. એક સમાધાન થયેલું અથવા બંધ થયેલું ખાતું બંને ગુમાવે છે.
• અપલોડ કરેલી ફાઇલો ભૂલી જવી. ડેટાબેઝ ફાઇલનો પાથ સંગ્રહ કરે છે; છબી પોતે સ્ટોરેજમાં રહે છે.
• બેકઅપ સ્ક્રિપ્ટમાં સિક્રેટ્સ છોડવા. કનેક્શન સ્ટ્રિંગ સ્ક્રિપ્ટના લખાણમાંથી નહીં, પર્યાવરણ ચલમાંથી વાંચો. જુઓ API કીને સુરક્ષિત કેવી રીતે રાખવી.

બેકઅપ અને Mythex

Mythex પ્રોજેક્ટમાં સમર્પિત Postgres ડેટાબેઝ હોઈ શકે છે, અને તેની કનેક્શન વિગતો વર્કસ્પેસ અને પબ્લિશ થયેલી એપમાં ઇન્જેક્ટ થાય છે. Mythex ડૉક્સ ડેટાબેઝ બેકઅપ કે રિસ્ટોર સુવિધાનું વર્ણન કરતા નથી, તેથી તમારો પોતાનો પ્લાન બનાવો: એજન્ટને ડમ્પ બનાવવા કહો, તેને ડાઉનલોડ કરો, અને સુરક્ષિત જગ્યાએ રાખો, ખાસ કરીને મોટા ફેરફારો પહેલાં. પ્રોજેક્ટ એક્સપોર્ટ (Pro) તમારો કોડ ધરાવે છે, જેમાંથી સિક્રેટ્સ અને node_modules બાકાત છે; તેમાં ડેટાબેઝની પંક્તિઓ નથી. ડૉક્સમાં Database અને Data ownership જુઓ. ડેટાબેઝ વિશે વધુ માટે Postgres શું છે વાંચો.

બેકઅપ ચેકલિસ્ટ

• તમે કેટલો ડેટા ગુમાવી શકો અને કેટલો સમય બંધ રહી શકો તે નક્કી કર્યું
• તપાસ્યું કે તમારો ડેટાબેઝ હોસ્ટ કયા ઓટોમેટિક બેકઅપ આપે છે
• તમારો પોતાનો ડમ્પ શેડ્યૂલ પર ચાલે છે, અને નિષ્ફળતા તમને ચેતવે છે
• નકલો ડેટાબેઝથી અલગ, મર્યાદિત ઍક્સેસ સાથે સંગ્રહાયેલી છે
• રીટેન્શન પોલિસી લખેલી છે
• અપલોડ કરેલી ફાઇલોનો પણ ડેટાબેઝ જેટલો જ બેકઅપ છે
• ખાલી ડેટાબેઝમાં રિસ્ટોર ચકાસ્યું છે, અને પંક્તિઓની સંખ્યા તપાસી છે
• દરેક જોખમી ફેરફાર પહેલાં બેકઅપ લેવાય છે

પ્રશ્નો